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ABSTRACT 


4  .  .  . 

COPERNICUS  IS  the  Navy's  C  I  architecture  envisioned  to 
enhance  command  and  control  for  the  Composite  Warfare 
Commander  (CWC) ,  Fleet  Commanders-in-Chief  (FLTCINCs)  and, 
eventually,  Unified  CINCs.  The  Communication  Support  System 
(CSS)  is  both  a  system  and  architecture  that  will  be 
instrumental  in  the  realization  of  the  Copernican  TADIXS 
networks.  The  purpose  of  this  thesis  is  to  provide  operations, 
communications  and  management  personnel  sufficient  information 
regarding  COPERNICUS  and  the  CSS  in  order  for  them  to  have  a 
basis  for  planning  and  managing  CSS  operations  at  its 
implementation . 


DTIC  QUALTTY  IIISPECTBD  & 


Aoo«sslon  For 

HTIS  GRAfcl 
DTIC  TAB 
Unanzioijnced 
Justlf Icatloa 


By. 


Distribution/ _ 

Availability  Codes 


Diet 


I 


iii 


Avail  and/or 
Spooial 


TABLE  OF  COMTENTS 


I .  INTRODUCTION 


1 


II.  THE  COPERNICUS  ARCHITECTURE  .  5 

A.  PURPOSE .  5 

B.  THE  SEW  CONCEPT .  6 

C.  THE  FOUR  PILLARS  OF  THE  COPERNICUS  ARCHITECTURE  7 

1.  GLOBIXS  (Global  Information  Exchange 

Systems)  .  7 

a.  Discussion .  7 

b.  GLOBIXS  Networks  .  10 

2.  The  CCC  (CINC  Command  Complex) .  12 

a.  Discussion .  12 

b.  The  Organizational  Building  Blocks  of  the 

CCC .  13 

3 .  TADIXS  (Tactical  Data  Information  Exchange 

Systems) .  16 

a.  Discussion .  16 

b.  TADIXS  Categories  .  18 

4.  The  TCC  (Tactical  Command  Center) .  18 

'  D.  THE  COPERNICUS  C^  DOCTRINE  .  20 

E.  THE  DEVELOPMENT  OF  COPERNICUS .  21 

F.  SUMMARY .  22 


iv 


III.  THE  COMMUNICATION  SUPPORT  SYSTEM  (CSS)  .  24 

A.  THE  CSS  ARCHITECTURE .  24 

1.  Discussion .  24 

2.  CSS  Architectural  Goals .  25 

B.  DESCRIPTION  OF  CSS .  26 

1.  CSS  Components .  26 

2.  Multimedia  Access  and  Resource  Sharing  ...  28 

3.  CSS  Segments .  30 

a.  The  Hardware  Segment .  30 

b.  The  Software  Segments .  31 

c.  The  Standard  Communications  Environment 

Communication  Services  (SCE  CS)  and  the 
SCE  Standard  Operating  Environment  (SCE 
SOE) .  37 

4.  CSS  Operator  Functions .  37 

C.  CSS  CONTRIBUTIONS  TO  C^ .  40 

1.  The  COPERNICUS  Architecture  .  41 

2.  CSS  Architectural  Goals .  41 

a.  Increased  Communications  Flexibility  and 

Survivability  via  Multimedia  Access  .  .  42 

b.  Increased  Responsiveness  to  Rapid  Changes 

in  Warfighting  Information  Transfer 
Requirements  .  43 

c.  Means  for  Incorporating  New  Communications 

Capabilities  .  44 


V 


d.  Maximized  Use  of  Existing  Communication 

Equipment .  44 

e.  Simplified  Communication  System  Operation 


and  Maintenance .  45 

D.  SUMMARY .  45 

IV.  THE  NAVY  EHF  COMMUNICATIONS  CONTROLLER  (NECC)  .  .  47 

A.  EHF  COMMUNICATIONS  TODAY .  47 

B.  THE  NAVY  EHF  COMMUNICATIONS  CONTROLLER  (NECC)  .  48 

1.  System  Description  .  49 

2.  Other  Capabilities  .  54 

C.  NECC  APPLICATIONS .  55 

1.  Near  Term  Applications .  58 

a.  EHF  Restoral  of  UHF  Networks .  59 


b.  Reduction  of  UHF  Network  Traffic  Loading  60 

c.  Support  of  No-notice  UHF  Requirements  .  60 


2.  Future  Applications  .  61 

D.  SUMMARY .  61 

V.  CSS/NECC  PLANNING  AND  MANAGEMENT  AT  IOC .  63 

A.  INTRODUCTION .  63 

B.  CSS  COMMUNICATIONS  PLANNING  APPROACH  .  64 

1.  Setting  Up  Services .  66 

a.  Accountable  and  Nonaccountable  Delivery  66 

b.  Service  Membership  .  67 

c.  Theater  Service  Priority  .  67 


Vi 


2 .  Setting  Up  Services  at  IOC .  69 

3.  Setting  Up  Resources .  71 

4.  Setting  Up  Resources  at  IOC .  73 

5.  Matching  Services  to  Resources  .  75 

a.  Assigning  Service  Priorities  .  75 

b.  Matching  Services  to  Resources  .  75 

c.  Percentage  Allocation  of  Resource  (PAR) 

and  Data  Precedence  Processing .  76 

6.  Matching  Services  to  Resources  at  IOC  ...  76 

a.  Assigning  Service  Priorities  .  77 

b.  Matching  Services  to  Resources  .  78 

c.  PAR  and  Data  Precedence  Processing  ...  79 

7.  Promulgating  the  Information  .  82 

C.  CONCLUSION .  87 

D.  SUMMARY .  88 

VI.  RECOMMENDATIONS  AND  CONCLUSION  .  90 

A.  RECOMMENDATIONS .  90 

1.  Planning  and  Management  at  CSS/NECC  IOC  .  .  90 

2.  NECC .  91 

3.  CSS .  91 

4.  COPERNICUS  and  CSS .  91 

B.  CONCLUSION .  92 

APPENDIX .  94 


vii 


LIST  OF  REFERENCES  . 


INITIAL  DISTRIBUTION  LIST 


viii 


I 


INTRODUCTION 


COPERNICUS  is  the  Navy  C^I  architecture  visualized  as  an 

interactive  framework  that  will  tie  together  the  command  and 

control  process  of  the  Navy  tactical  commander  afloat,  the 

Joint  Task  Force  (JTF)  commander,  the  numbered  fleet  commander 

and  others  with  the  CINCs  ashore  [Ref.  l:p.  3-1].  It  will 

consist  of  four  principal  segments,  or  pillars:  the  Global 

Information  Exchange  Systems  (GLOBIXS) ,  CINC  Command  Complex 

(CCC) ,  Tactical  Data  Information  Exchange  Systems  (TADIXS) , 

and  Tactical  Command  Center  (TCC) .  By  making  use  of  the 

newest  communications  and  computer  network  technology,  it  is 

2 

intended  to  see  Command  and  Control  (C  )  into  and  through  the 
21st  century. 

The  Communications  Support  system  (CSS)  will  allow  the 
tactical  commander,  through  the  Space  and  Electronic  Warfare 
Commander  (SEWC) ,  to  control  Copernican  TADIXS  in  the  same 
manner  that  other  commanders  control  ASW,  ASUW  or  AAW  [Ref. 
l:p.  8-11].  Thus,  CSS  is  to  become  an  integral  part  of  the 
COPERNICUS  a. chitecture.  With  an  Initial  Operational 
Capability  (IOC)  of  FY94,  CSS  is  planned  to  route  data  between 
the  TCC  afloat  and  the  CCC  ashore.  At  its  IOC,  the  Navy  EHF 
Communications  Controller  (NECC)  is  a  system  that  will  operate 
under  CSS  with  the  new  Navy  EHF  Satellite  Program  (NESP) 
terminals  at  a  speed  of  2.4  kbps.  Thus,  EHF  satellite 
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communications  (SATCOM)  will  become  the  first  bearer  service, 
or  communications  medium,  to  be  provided  as  a  Copernican 
TADIXS.  Additional  bearer  services  such  as  UHF,  SHF,  HF  and 
commercial  satellite  communications  (SATCOM)  are  also  planned 
for  incorporation  into  CSS. 

Although  COPERNICUS  intends  that  the  "command  and  control 
universe"  revolve  around  the  tactical  commander,  the  Fleet 
Commander-in-Chief  (FLTCINC)  retains  overall  responsibility 
for  operations  within  his  Area  of  Responsibility  (AOR) ,  both 
as  Naval  FLTCINC  and  as  component  commander  to  his  Unified 
CINC.  This  thesis  is  intended  to  provide  an  informational 
document  for  FLTCINC  staff  planners,  operators,  communicators 
and  intelligence  personnel  alike  so  that  they  may  gain  a 
better  understanding  of  the  CSS  and  NECC,  and  of  how  these 
systems  will  work  together  toward  fulfilling  the  plans 
conceived  in  the  COPERNICUS  architecture. 

This  thesis  is  also  intended  to  provide  the  FLTCINC, 
numbered  fleet  commander  and  other  cognizant  organizations  a 
basis  for  discussion  in  managing  CSS  and  NECC  at  IOC  for 
communications  planning  purposes.  Ideas  will  be  presented  so 
that  use  and  management  of  these  systems  within  a  FLTCINC 's 
AOR  may  be  determined  and  promulgated  prior  to  the  systems' 
IOC.  Security  issues  will  not  be  addressed  in  this  thesis. 

For  the  purpose  of  simplification,  a  top-down  discussion 
of  the  Copernican  structure  and  how  each  system  fits  into  the 
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larger  picture  will  be  presented.  The  following  paragraphs 
delineate  subjects  which  will  be  discussed  by  chapter. 

Chapter  II  will  briefly  describe  the  COPERNICUS 
architecture  and  its  four  pillars  as  currently  envisioned.  A 
short  discussion  of  the  SEW  concept  is  included.  TADIXS  and 
its  relationship  to  the  CSS  will  be  introduced  to  the  reader. 

Chapter  III  will  discuss  CSS.  Discussion  vrill  include  a 

more  detailed  description  of  its  functions  and  segments,  and 

the  capabilities  it  is  planned  to  provide.  Its  relationship 

2 

to  COPERNICUS  and  its  benefits  to  C  will  also  be  covered. 

Chapter  IV  will  describe  the  NECC.  Included  are 
discussions  on  EHF  communications  today,  NECC's  relationship 
to  CSS,  its  functions,  segments,  and  the  capabilities  it  is 
planned  to  provide  at  IOC.  NECC  applications  both  in  the  near 
and  far  term  will  be  presented.  An  appendix  to  the  thesis 
provides  a  schedule  of  the  capabilities  planned  to  be  provided 
by  the  NECC  in  the  future. 

Chapter  V  will  bring  together  the  previous  discussions 
with  a  description  of  the  NESP  terminal  in  order  to  develop  a 
CSS  communications  plan  (COMMPLAN)  and  a  CSS  connection  plan 
(CNCTNPLAN) .  A  planning  approach  will  be  explained  in  order 
that  planners  may  get  an  idea  about  CSS  communications 
planning  prior  to  IOC.  Issues  will  be  identified  that  may 
require  discussion  prior  to  CSS/NECC  implementation. 
Recommendations  will  be  made  as  to  how  those  issues  might  be 
resolved. 
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Chapter  VI  concludes  the  thesis.  A  brief  summary  and 
recommendations  will  be  presented. 
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II.  THE  COPERNICUS  ARCHITECTURE 


A.  PURPOSE 

The  tremendous  growth  of  Navy  telecommunications,  the 
increase  in  demand  by  its  users  and  the  acknowledgment  of  its 
critical  role  in  supporting  command  and  control  (C^)  have 
resulted  in  the  identification  of  three  major  problems  with 
the  current  Navy  telecommunications  system  [Ref.  2:p.  2]: 


•  Limited  ability  to  separate  critical  sensor  and 

operational  traffic  from  mission  support  and/or 

administrative  traffic.  During  conflict,  decision  makers 
must  receive  only  the  information  they  require  in  order  to 
plan  their  actions.  Administrative  traffic  competes  with 
those  messages  whose  timely  delivery  is  crucial  to 
successful  operations. 

•  Overreliance  on  narrative  message  traffic  and  the  lack  of 
common  information  formats  inundate  the  warfiahtina 
commander  in  data  that  cannot  be  readily  assimilated  and 
used.  Precious  time  is  often  wasted  in  either 
interpreting  or  sorting  through  information  from  numerous 
sources  in  order  to  make  a  critical  decision. 

•  Limited  technical  oversight  of  today's  Command.  Contr(^l. 
Communications.  Computers  and  Intelligence  fc  I) 
architecture.  Separation  and  lack  of  coordination  among 
Naval  cl  components,  as  well  as  joint  and  allied 
components,  often  lead  to  duplication  of  effort,  overtaxed 
communications  resources,  interoperability  and  security 
issues. 


Additionally,  with  the  massive  amounts  of  information  to 
be  processed,  reduced  manning,  and  the  complexity  and 
sophistication  of  emerging  systems,  new  computer  architectures 
and  applications  will  be  required  [Ref.  2:p.  14].  Only  an 
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improved  information  management  system  that  is  state-of-the- 
art  and  can  keep  up  with  rapidly  developing  technological 
advances  in  telecommunications  can  remedy  these  problems. 

In  order  to  achieve  a  cohesive  C*I  architecture  that  will 
fully  support  C^,  the  COPERNICUS  architecture  has  been 
defined.  COPERNICUS  will  be  constructed  as  an  interactive 
framework  that  ties  together  the  command  and  control  process 
of  the  Navy  tactical  commander  afloat,  the  Joint  Task  Force 
(JTF)  commander,  the  numbered  fleet  commander,  and  others  with 
the  CINCs  ashore  [Ref.  l:p.  3-1].  It  is  also  planned  to 
support  joint  and  Allied  operations  in  the  future. 

B.  THE  SEW  CONCEPT 

The  Warfare  Mission  Area  (WMA)  of  Space  and  Electronic 
Warfare  (SEW)  was  established  in  1989  by  the  Chief  of  Naval 
Operations  (CNO) .  The  WMA  is  seen  as  the  Navy's  commitment  to 
bring  together  elements  of  Electronic  Warfare  (EW) ,  C*I, 
surveillance  and  other  tactical  and  strategic  assets  into  a 
seamless  SEW  system.  Together  with  other  warfare  commanders 
such  as  the  Anti-Air  Warfare  Commander  (AAWC) ,  Anti-Submarine 
Warfare  Commander  (ASWC) ,  and  Anti-Surface  Warfare  Commander 
(ASUWC) ,  the  SEWC  will  provide  support  to  the  Composite 
Warfare  Commander  (CWC)  .  [Ref*.  l:p.  9-2] 

The  SEWC's  role  is  anticipated  to  become  fully  developed 
within  approximately  ten  years.  In  support  of  this 
development,  SEW  doctrine  is  currently  being  established.  A 
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SEW  Naval  Warfare  Publication  (NWP)  is  being  produced,  and  SEW 
subsystems  are  being  identified.  COPERNICUS,  a  SEW  subsystem 
intended  to  support  all  commanders,  will  be  delegated  to  the 
SEWC  by  the  CWC  [Ref.  l:pp.  9-2,  1-9]. 

C.  THE  FOUR  PILLARS  OF  THE  COPERNICUS  ARCHITECTURE 

The  COPERNICUS  architecture  will  consist  of  four  pillars: 
the  Global  Information  Exchange  Systems  (GLOBIXS) ,  the  CINC 
Command  Complex  (CCC) ,  the  Tactical  Data  Information  Exchange 
Systems  (TADIXS) ,  and  the  Tactical  Command  Center  (TCC) . 

1.  GLOBIXS  (Global  Information  Exchange  Systems) 
a .  Discussion 

The  GLOBIXS  are  planned  as  worldwide  or  theaterwide 
limited  access,  high  speed,  highly  concentrated  virtual 
networks  which  will  join  shore-based  commands  or  activities  of 
like  missions  or  interests  [Ref.  l:p.  4-1].  (A  virtual 
network  is  one  which  exists  only  for  the  time  it  takes  to 
exchange  information  among  users.)  Besides  allowing  GLOBIXS 
members  to  send  information  to  other  shore-based  members, 
GLOBIXS  will  transport,  standardize,  and  concentrate  shore- 
based  sensor,  analytic,  command  support,  administrative,  and 
other  information  for  further  passage  to  commanders  afloat 
[Ref.  l:p.  4-1]. 

GLOBIXS  terminal  equipment  are  slated  to  consist  of 
STU-IIIs  and  the  Fleet  All-Source  Tactical  Terminals  (FASTTs) , 
Copernican  standardized  computer  hardware  [Ref.  l:p.  4-15]. 
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The  FASTTs  of  members  of  a  particular  GLOBIXS  network  will 
share  the  same  application  software,  and  will  be  linked  to  the 
FASTT  of  their  corresponding  Operations  Watch  Center  (OWC) 
operator  at  the  CCC  [Ref.  3].  These  operators,  acting  in 
accordance  with  tailored  doctrine  established  by  each  Officer 
in  Tactical  Command  (OTC) ,  will  have  the  technological 
capability  to  determine  whether  and  to  what  degree  to  filter 

shore-based  information  [Ref.  4:p.  90]. 

«  .  .  2 
The  tailored  doctrine  will  be  a  CWC's  C  plan, 

selected  from  matrices  in  a  future  COPERNICUS  management  NWP 

that  will  describe  COPERNICUS  GLOBIXS-TADIXS  configurations 

[Ref.  3].  The  CCC  personnel  will  consolidate,  size,  and 

format  the  shore-based  information  from  the  GLOBIXS  and  send 

it  over  the  appropriate  TADIXS  [Ref.  4  ;p.  90].  The 

collection  of  GLOBIXS  information  the  CWC  selects  may  be 

independent  from  that  of  another  CWC  in  a  different 

communications  area  (COMMAREA) . 

Thus,  it  may  be  stated  that  CCC  personnel  will 

anchor — filter,  sort,  analyze,  and  move — GLOBIXS  information 

for  the  tactical  commander,  and  that  GLOBIXS  should  afford  the 

Composite  Warfare  Commander  (CWC)  the  capability  to  receive 

information  tailored  to  his  needs  in  order  to  fulfill  his 

• 

specific  mission  [Ref.  l:p.  3-2].  If  he  so  desires,  the 
tactical  commander  may  decide  that  some  or  all  GLOBIXS 
information  be  anchored  by  afloat  personnel,  based  on  his 
personal  preference  [Ref.  l:p.  3-13].  Figure  1  [Ref.  l;p.  3- 
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4]  illustrates  how  the  CCC  anchors  will  act  as  interfaces,  or 
gateways,  between  the  GLOBIXS  and  TADIXS  virtual  networks, 
taking  information  from  their  respective  GLOBIXS  networks  to 
filter  and  consolidate  it  into  a  concise,  uniform  package  that 
can  be  sent  over  the  TADIXS  to  the  TCCs.  These  personnel  will 
similarly  transmit  "anchored”  TADIXS  information  over  their 
respective  GLOBIXS  networks  [Ref.  l:p.  3-2]. 

Some  programs  related  to  GLOBIXS  development  are 
the  Defense  Data  Network  (DDN) ,  a  worldwide  digital  packet 
switched  network;  the  Defense  Message  System  (DMS) ,  scheduled 
to  replace  AUTODIN;  and  the  Defense  Switched  Network  (DSN), 
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the  primary  DOD  telecommunications  network  which  has  evolved 
from  the  AUTOVON  network.  [Ref.  l:p.  4-24] 


b.  GLOBIXS  Networks 

As  stated  previously,  the  GLOBIXS  are  intended  to 
join  shore-based  commands  of  like  missions  or  interests. 
Eight  GLOBIXS  networks  are  initially  planned.  Five  GLOBIXS 
are  operationally  oriented  and  contain  the  major  sensor  and 
analytic  nodes,  both  Navy  and  national: 

•  GLOBIXS  A  for  Signals  Intelligence  (SIGINT) ; 

•  GLOBIXS  B  for  Antisubmarine  Warfare  (ASW) ; 

•  GLOBIXS  C  for  Space  and  Electronic  Warfare  (SEW) ; 

•  GLOBIXS  E  for  Imagery;  and 

•  GLOBIXS  F  for  Data  Base  Management  (where  files  may  be 
moved  to  and  from  TCCs) .  [Ref.  l:pp.  4-2,  4-19] 

GLOBIXS  D  will  be  a  multimedia  (video¬ 
teleconferencing,  facsimile,  secure  voice)  High  Command 
(HICOM)  network,  connecting  major  commands  such  as  the 
FLTCINC,  Joint  Task  Force  commander  and  numbered  fleet 
commander  [Ref.  3].  Its  format  will  depend  on  the  medium 
being  used. 

The  remaining  two  GLOBIXS  will  be  primarily 
supportive  in  nature: 

•  GLOBIXS  G,  the  Research  &  Development  Information  Exchange 
System,  which  will  provide  for  exchange  of  information 
among  such  organizations  as  Navy  laboratories  and  weapons 
testing  facilities 
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•  GLOBIXS  H,  the  Navy  Information  Exchange  System  (NAVIXS) , 
the  Navy's  implementation  of  the  Defense  Message  System 
(DMS) ,  intended  to  support  traditional  narrative  message 
traffic.  [Ref.  l:p.  4-2] 

The  construction  of  a  GLOBIXS  is  expected  to  be 
accomplished  by  little  more  than  the  connection  of  standard 
hardware  onto  a  Defense  Communications  System  (DCS)  backbone 
at  a  proposed  GLOBIXS  node  with  tailored  software  applications 
[Ref.  3].  Therefore,  a  contingency  GLOBIXS  could  be  created 
to  support  no-notice  operations  if  required.  Similarly, 
additional  GLOBIXS  may  be  added  to  the  architecture  as  the 
need  arises. 

The  use  of  COPERNICUS  Common  (COPCOM) ,  the  Navy's 
planned  binary  digital  format,  and  OPNOTE  (a  message  format 
similar  to  that  used  by  OTCIXS,  the  Officer  in  Tactical 
Command  Information  Exchange  Subsystem)  by  net  members  of 
GLOBIXS  A,  B  and  C  should  provide  true  exchange  of  digital 
information  [Ref.  l:p.  4-16],  characterized  by  voice,  imaging 
and  digital  data,  not  principally  character-oriented  textual 
information  such  as  the  AUTODIN  message  format  being  used 
today  [Ref.  3].  The  use  of  digital  infoimation  will  increase 
message  traffic  speed  and  volume  over  those  bearer  services, 
in  this  instance  DCS  and  commercial  circuits,  capable  of 
supporting  them. 
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2.  Th«  CCC  (CINC  Command  Complex) 
a .  Discussion 

The  CCC  will  include  a  nvunber  of  existing 
organizations  brought  together  technologically  by  common 
workstations  (FASTTs)  connected  to  a  metropolitan  area  network 
(MAN)  [Ref.  l:p.  5-2].  The  CCC  MAN,  like  GLOBIXS,  is  a 
virtual  network,  part  of  the  Base  Information  Transfer  System 
(BITS) ,  a  backbone  scheme  for  basewide  communications  systems 
integration,  which  will  interface  to  the  DCS  [Ref.  l:p.  5-15]. 
The  wideband  CCC  MAN  will  connect  to  many,  smaller,  local  area 
networks  (LANs) ,  also  part  of  BITS,  of  those  shore-based  staff 
and  command  organizations  whose  information  provides  strategic 
and  tactical  mission  support  to  the  FLTCINC  [Ref.  l:p.  8-2]. 

CCCs  will  be  located  at  Oahu,  Hawaii,  Norfolk, 

Virginia,  and  Naples,  Italy,  and  will  be  managed  by 

CINCPACFLT,  CINCLANTFLT  and  CINCUSNAVEUR,  respectively.  Each 

CCC  may  be  constructed  differently.  A  LAN  within  each  CCC 

will  provide  gateways  to  the  larger  MAN,  connecting  the 

centers  and  providing  gateways  to  TADIXS  through  the 

Communication  Support  System  (CSS)  and  to  shore  GLOBIXS 

networks  [Ref.  l;p.  5-6].  In  other  words,  besides  information 

generated  by  the  CCC,  both  GLOBIXS  and  TADIXS  information  will 

« 

travel  over  the  CCC  MAN. 

Much  like  GLOBIXS,  the  CCC  MAN  is  also  planned  to 
be  flexible  and  dynamic  by  allowing  the  FLTCINC  the  capability 
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to  add  or  delete  members  from  its  configuration  according  to 
operational  scenario.  Thus,  the  CCC  would  also  be  capable 
of  incorporating  compatible  liAN(s)  of  the  Unified  CINC, 
converting  itself  from  a  Navy  network  to  a  Unified  network  in 
order  to  support  any  joint  or  allied  operations  or  the 
eventual  joint  architecture.  [Ref.  l:p.  5-2] 

The  WWMCCS  ADP  Modernization  (WAM) ,  is  a  program 
under  which  current  ADP  systems  are  being  redesigned  and 
replaced.  ASWOC  Modernization  is  the  installation  of  a  LAN- 
based  architecture  at  all  ASW  Operations  Centers.  Both 
programs  are  related  to  the  development  of  the  CCC,  in 
addition  to  BITS.  [Ref.  l;p.  5-15] 

b.  The  Organizational  Building  Blocks  of  the  CCC 

As  previously  discussed,  it  is  planned  that  the  CCC 
will  have  the  capability  to  manage  the  flow  of  information  for 
the  tactical  commander.  Six  organizational  building  blocks 
are  planned  to  constitute  the  CCC  [Ref.  l:p.  5-4]. 

The  Fleet  Command  Center  (FCC)  is  the  center  of 
FLTCINC  operations.  In  fulfillment  of  its  duties  to  support 
the  FLTCINC  in  the  exercise  of  their  responsibilities  as  naval 
component  commanders,  the  FCC  will  manage  theater  resources, 
interface  with  designated  net  members  for  operational  tasking 
and  coordination  and  receive  various  informational  reports  as 
required  [Ref.  l:pp.  5-7  -  5-8].  The  FCC  may  also  communicate 
via  the  CCC  MAN  with  the  numbered  fleet  commander,  CWC, 
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operational  units,  other  FCCs  and  supporting  CINCs.  The  FCC 
will  anchor  GLOBIXS  D,  the  Connand  GLOBIXS. 

The  Operations  Watch  Center  (OWC) ,  whose  membership 
will  be  controlled  by  the  CCC,  is  designated  to  be  the  heart 
of  the  COPERNICUS  architecture  ashore,  serving  as  the  gateway 
for  the  CWC  into  the  GLOBIXS  organization.  As  previously 
mentioned,  the  OWC's  operators  and  their  FASTTs  will  be 
interactively  connected  to  the  watchstanders  of  the  other 
organizational  building  blocks  listed  here,  and  can  be  viewed 
as  a  collection  of  GLOBIXS  anchor  desks  and  other  personnel 
assembled  to  suit  the  mission  being  executed.  OWC  personnel 
will  be  a  part  of,  and  served  by,  the  CCC  MAN,  rather  than  a 
physically  co-located  structure.  In  other  words,  anchor  desks 
of  the  GLOBIXS  networks  will  be  situated  at  each  of  the  other 
organization  building  blocks.  [Ref.  l;p.  5-4] 

The  Space  and  Electronic  Warfare  (SEW)  Center  will 
be  responsible  for  strategic  and  theater-level  SEW,  and  is 
planned  to  anchor  GLOBIXS  C,  and  will  act  as  the  interface 
between  GLOBIXS  C  and  the  SEW  TADIXS  [Ref.  l:p.  5-5].  The  SEW 
Center  may  also  be  delegated  management  functions  of  some  or 
all  TADIXS  by  the  CWC  [Ref.  l:p.  6-13]. 

The  Research  Center  will  anchor  and  provide 
information  retrieval  capability  for  the  CCC  through  GLOBIXS 
F,  the  Data  Base  GLOBIXS.  It  will  also  house  common  data 
bases  for  the  CCC  MAN.  [Ref.  l:p.  5-5] 
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The  Joint  Intelligence  Center  (JIC)  will  consist  of 
the  Fleet  Intelligence  Center  (FIC) ,  which  will  anchor  GLOBIXS 
E,  and  act  as  the  interface  between  GLOBIXS  E  and  TADIXS 
imagery;  the  Fleet  Ocean  Surveillance  Intelligence  Center 
(FOSIC)  ,  providing  operational  intelligence  (OPINTEL)  ;  and  the 
Cryptologic  Support  Group  (CSG) ,  which  will  anchor  GLOBIXS  A 
and  act  as  the  interface  with  both  SIGINT  GLOBIXS  and  TADIXS 
[Ref.  l:p.  5-5].  Similarly,  the  ASW  Centers  will  anchor 
GLOBIXS  B  and  interface  with  both  ASW  GLOBIXS  and  TADIXS  [Ref. 
l:p.  5-5]. 

As  shown  in  Figure  2  [Ref.  l:p.  8-1],  the  GLOBIXS 
and  the  CCC  will  comprise  the  shore  side  of  information 
management  in  the  COPERNICUS  architecture.  The  final  two 


Figure  2.  The  Pillars  of  the  COPERNICUS  Architecture 
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pillars  of  the  architecture,  TADIXS  and  the  TCC,  will 
constitute  the  a float/air/ ground  warfighting  portion. 

3.  TADIXS  (Tactical  Data  Infonation  Exchange  Systems) 
a.  Discussion 

TADIXS  are  to  be  the  virtual  networks  which  will 
support  afloat/ground/airborne  Tactical  Command  Centers 
(TCCs) .  TADIXS  are  envisioned  as  information  nets  time¬ 
sharing  communications  circuitry  over  a  broad  range  of  bearer 
services,  transmission  media  such  as  UHF,  SHF,  EHF  and 
commercial  SATCOM  and  HF.  The  information  of  one  TADIXS  may 
be  supported  by  several  channels  and,  conversely,  one  channel 
may  support  several  TADIXS  [Ref.  l:p.  6-1]. 

What  percentage  of  time  a  TADIXS  net  will  share 
with  other  TADIXS  information  and  which  medium  will  be  used 
will  be  determined  by  the  CWC,  based  upon  the  future  NWP 
matrix  previously  discussed.  The  CWC  may  delegate  the 
responsibility  for  management  and  control  of  the  TADIXS  to  the 
SEW  Commander  (SEWC)  or  the  SEW  Coordinator  [Ref.  2:p.  18]. 

TADIXS  will  be  defined  by  five  elements: 

•  user  software/data  addressing ,  HMI  software  will  provide 
TADIXS  information  to  the  appropriate  afloat  commander. 
In  turn,  that  commander  will  address  the  information  to 
the  cognizant  afloat  FASTTs  requiring  that  information. 

•  format,  either  COPCOM  or  OPNOTE  (digital),  narrative 
message  (textual) ,  voice,  or  video 

•  subscribership,  both  GLOBIXS  and  TADIXS  members  designated 
as  net  subscribers 
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•  duration,  either  permanent,  or  a  specified  time  frame 

•  communications  pathway,  determined  via  the  CSS,  dependent 
upon  available  path,  data  format,  degree  of  jam- resistance 
required,  the  capabilities  of  other  TADIXS  subscribers, 
and  the  duration  of  the  TADIXS.  [Ref.  l:pp.  6-14  -  6-15] 

These  capabilities  will  be  afforded  to  TADIXS 
management  by  the  CSS,  which  will  provide  the  tactical 
transmission  systems  and  the  networking  capabilities  to 
support  TADIXS  communications  services  [Ref.  2:p.  5].  CSS 
will  provide  the  ability  for  the  CWC  (through  the  SEWC)  to 
control  Copernican  TADIXS  in  the  same  manner  that  other 
commanders  control  ASW,  ASUW  or  AAW  [Ref.  l:pp.  8-11].  CSS 
will  be  the  framework  for  management  of  control  of 
communications  assets  among  TCCs.  How  this  will  be 
accomplished  will  be  discussed  in  the  next  chapter. 

The  TADIXS  will  enhance  communications  among  TCCs 
and  augment  command  and  control  capabilities: 


•  by  nearly  eliminating  the  necessity  for  the  narrative 
message  through  its  use  of  binary  data  transfer  (NAVIXS 
will  still  provide  narrative  message  traffic) ; 

•  by  providing  greater  efficiency  and  communications 
capacity  by  its  virtual  networking  and  the  use  of  software 
which  will  provide  information  (via  high  resolution 
graphics  and  imagery)  more  efficiently  and  powerfully  than 
text ; 

•  by  allowing  multimedia  access  via  the  CSS;  and 

•  by  providing  jam  resistance  capability.  [Ref.  l;p.  6-4] 


Some  programs  related  to  TADIXS  development  besides 
the  CSS  are  the  Advanced  Narrowband  Digital  Terminal  (ANDVT) , 
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which  supports  secure  digital  voice  or  data  communications; 
Submarine  Satellite  Information  Exchange  Siibsystem  (SSIXS)  II, 
an  upgrade  to  the  current  SSIXS  UHF  SATCOM  network;  and  the 
UHF  Follow-on  (UFO)  Satellite  System,  designed  to  replace 
FLTSATCOM  satellites.  [Ref.  l:pp.  6-15  -  6-17] 
b.  TADIXS  Categories 

All  TADIXS,  less  NAVIXS  TADIXS,  are  being  designed 
in  formats  other  than  narrative  messages  [Ref.  l:p.  6-2]. 
Four  types,  or  categories,  of  TADIXS  are  planned  [Ref.  l:p.  6- 
1]  : 


•  Command  TADIXS.  These  multiformatted  TADIXS  will  support 
communications  among  higher  level  commanders  (National 
Command  Authorities,  Unified  CINCs,  FLTCINCs,  CWC)  and 
those  between  the  CWC  and  his  subordinate  commanders 
(Navy,  joint  or  Allied) . 

•  Support  TADIXS.  These  TADIXS  will  include,  for  example, 
Logistics,  Environmental,  Data  Base  File  Transfer  and 
Imagery  TADIXS.  NAVIXS  TADIXS  is  contained  here  as  well. 
NAVIXS  is  anticipated  to  be  the  only  TADIXS  to  support 
narrative  message  traffic. 

•  Direct  Targeting  TADIXS.  These  TADIXS  will  be  tailorable 
to  specific  geographic  areas  and  can  be  modified  for 
Allied  usage. 

•  Force  Operations  TADIXS.  These  TADIXS  will  be  constructed 
around  the  tactical  force.  Their  makeup  will  be  dependent 
on  that  force,  whether  it  be  Joint  Task  Force  (JTF) , 
Carrier  Battle  Group  (CVBG)  or  Marine  Air/Ground  Task 
Force  (MAGTF) . 


4.  The  TCC  (Tactical  Command  Center) 

A  TCC  will  be  defined  by  warfighting  functions 
performed  (e.g.,  CWC/OTC,  SEWC,  ASWC) .  Thus,  one  platform 
could  have  more  than  one  TCC,  and  conversely,  a  single  TCC 
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could  be  located  on  several  platforms  [Ref.  Itp.  7-5].  It 
will  consist  of  the  tactical  centers  of  a  battle  group 
commander,  his  units  and  command  centers  (each  of  these  also 
considered  a  TCC)  of  multi force  commanders  whether  afloat, 
ashore  or  airborne,  thus  providing  connectivity  among  all  of 
its  members.  TCCs  will  be  hierarchically  determined  according 
to  operational  plans  for  a  mission  [Ref.  l:p.  7-6]. 

The  future  installation  of  LANs  using  fiber  optic 
busses  is  intended  to  connect  all  operational  spaces  aboard 
ships  [Ref.  l:p.  7-2].  These  afloat  LANs,  using  FASTTs  with 
application  software  similar  to  their  counterparts  ashore, 
will  receive  information  via  the  TADIXS.  This  enhanced 
capability  within  the  tactical  commander's  ship  and  within  the 
ships  of  his  subordinates,  as  well  as  the  ability  to  configure 
his  system  (receipt  of  external  information)  according  to 
the  needs  of  his  mission,  are  expected  to  facilitate  and 
improve  his  decisionmaking  capacity. 

The  Navy  Tactical  Command  System  Afloat  (NTCS-A)  is 
related  to  the  development  of  the  TCC.  It  is  to  be  composed 
of  such  systems  as  the  Joint  Operational  Tactical  System 
(JOTS) ;  the  Electronic  Warfare  Coordination  Module  (EWCM) , 
which  will  provide  planning,  decision  aids,  and  automated  data 
processing  support  for  the  CWC/OTC  and  Electronic  Warfare 
Coordinator  (EWC) ;  the  Afloat  Correlation  System  (ACS) ,  a 
near-real-time  support  system  for  automated  correlation, 
fusion  and  other  analytical  manipulation  of  multisource  threat 


information;  and  the  Naval  Intelligence  Processing  System 
(NIPS)  ,  which  will  support  analysis  packaging  and  distribution 
of  intelligence  information  for  the  CWC/OTC  and  subordinate 
warfare  commanders  and  coordinators.  [Ref.  l:pp.  7-10  -  7-11] 
Figure  3  [Ref.  l:p.  8-2]  should  assist  the  reader  in 


conceptualizing  how  the  four  pillars  will  interact 
technologically.  The  figure  illustrates  information 

technology  ashore  (GLOBIXS,  CCC)  and  information  technology 
afloat  (TADIXS,  TCC) . 

D.  THE  COPERNICUS  C^  DOCTRINE 

The  COPERNICUS  architecture  aims  to  provide  the  CWC 

information  improved  both  in  accuracy  and  in  timeliness, 

affording  him  the  precision,  time  and  options  representative 
2 

of  a  C  capability  commensurate  with  today's  ever- improving 
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technology.  Upon  implementation  of  the  COPERNICUS 
architecture,  the  four  pillars,  their  features  and 
capabilities  will  provide  the  tactical  commander  with  six 
doctrinal  choices  to  make  according  to  his  mission  [Ref.  l:p. 
3-1] : 


•  Selection  of  technological,  doctrinal  and  organizational 
components  of  the  TCC.  That  is,  configuration  of  the  TCC 
and  the  TCCs  of  his  subordinate  units  to  reflect  the 
mission. 

•  Determination  of  which  GLOBIXS  information  will  be 
anchored  by  CCC  personnel  and  which,  if  any,  by  his 
personnel  afloat. 

•  Selection  of  desired  GLOBIXS  information  by  network  and 
which  cases  (data  precedences)  will  warrant  receipt  of 
that  information.  This  option  may  be  changed  by  the  CWC 
in  accordance  with  any  changes  in  the  mission. 

•  Selection  of  communications  services  and  addressing  them 
to  chosen  units  and  TCC  positions. 

•  Selection  of  TADIXS  mix:  where  information  will  be  sent 
and  how  it  will  be  displayed. 

•  Selection  via  CSS  of  communications  resources  to  support 
the  TADIXS  virtual  networks.  [Ref.  l:p.  3-12  -  3-15] 


As  previously  mentioned,  some  of  these  functions  may  be 
delegated  to  the  afloat  SEWC  or  even  the  SEW  center  ashore 
[Ref.  l:p.  6-13]. 


E.  THE  DEVELOPMENT  OF  COPERNICUS 

« 

In  the  next  decade,  the  accomplishment  of  four  tasks  are 
required  to  begin  achieving  the  COPERNICUS  architecture: 
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•  Build  GLOBIXS  and  the  analytical  tools  which  will  be  used 
by  the  networks'  users 

•  Formulate  and  format  the  right  mix  of  TADIXS 

•  Construct  the  FCC,  CCC  and  TCCs 

•  Systemize  our  [SATCOM]  constellations,  develop  a  dynamic 
multiplexing  system,  and  incorporate  DON  ashore  to  build 
the  architecture's  communications  backbone.  [Ref.  4:p.  92] 

Additionally,  planned  TADIXS  bearer  services  must  be  further 

developed  so  that  they  may  provide  the  maximum  amount  of 

throughput  [Ref.  l:p.  6-9]. 

.  2 

Thus,  the  previously  stated  C  enhancements  will  be 
realized  incrementally,  in  concurrence  with  development  of  the 
COPERNICUS  architecture.  COPERNICUS  development  will  be 
achieved  in  steps  by  implementation  of  various  related 
systems.  CSS,  the  initial  implementation  of  Copernican 
TADIXS,  will  be  discussed  in  the  following  chapter. 

F.  SUMMARY 

.  .  4 

In  order  to  achieve  a  cohesive  C  I  architecture  that  will 
fully  support  C^,  the  COPERNICUS  architecture  has  been 
defined.  COPERNICUS  will  be  constructed  as  an  interactive 
framework  that  ties  together  the  command  and  control  process 
of  the  Navy  tactical  commander  afloat,  the  Joint  Task  Force 
(JTF)  commander,  the  numbered  fleet  commander,  and  others  with 
the  CINCs  ashore.  COPERNICUS  is  intended  to  support  all 
commanders,  and  will  be  delegated  to  the  SEW  Commander  (SEWC) 
by  the  Composite  Warfare  Commander  (CWC) .  COPERNICUS 
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development  will  be  achieved  in  steps  by  implementation  of 
various  related  C4I  systems.  CSS  will  be  the  initial 
implementation  of  Copernican  TADIXS  chapter. 


III.  THE  CONMDmCATIOM  SUPPORT  SYSTEM  (CSS) 


A.  THE  CSS  ARCHITECTURE 
1.  Discussion 

CSS  is  more  than  a  system.  CSS  is  a  communications 
sub-architecture  that  enhances  battle  force  communications 
connectivity,  flexibility  and  survivability  through  multi- 
media  access  and  resource  sharing.  The  CSS  is  to  be  an 
integral  part  of  COPERNICUS.  As  shown  in  Figure  3, 
information  will  travel  across  the  GLOBIXS,  over  the  CCC  MAN, 
and  then  to  the  CSS  terminals  located  at  TCCs  via  TADIXS. 
Conversely,  information  will  travel  from  CSS  terminals  via 
TADIXS  to  the  CCC  MAN,  then  on  to  the  GLOBIXS,  thus  providing 
the  means  for  Copernican  ship/ shore  ship  communications.  [Ref. 
3] 

Like  COPERNICUS,  the  CSS  architecture  is  also 
evolutionary;  it  will  achieve  full  realization  incrementally 
by  integrating  existing  dedicated  communications  systems  and 
by  implementing  new  systems  to  interface  with  it.  The  CSS 
architecture  will  also  provide  direction  to  the  design  of 
those  new  systems  [Ref.  5:p.  2-2]. 

The  CSS  modular  approach  will  reduce  development  and 
life  cycle  support  costs  of  future  systems  substantially  by 
the  use  of  open  system  architecture  principles  [Ref.  3].  An 
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open  system  architecture  provides  interoperability  between  an 
existing  system  and  new  technologies.  Thus,  CSS  will  provide 
flexibility  through  reconfiguration  of  either  CSS  hardware  or 
software,  and  an  expansion  capability  to  support  new 
technologies  as  well  [Ref.  6:p.  36].  CSS  intends  to 

accommodate  system  improvements  with  minimal  disturbance  or 
adjustment  to  what  has  already  been  implemented  [Ref.  5:pp.  2- 
2  -  2-4] . 

The  CSS  will  be  the  first  implementation  of  the 
COPERNICUS  architecture  and,  in  turn,  the  Navy  EHF 
Communications  Controller  (NECC)  will  be  the  first  increment 
of  the  CSS  architecture,  providing  an  EHF  SATCOM  capability  to 
the  Copernican  TADIXS.  Initial  Operational  Capability  (IOC) 
of  NECC  under  CSS  is  scheduled  for  FY94. 

2.  CSS  Architectural  Goals 

The  operational  and  procurement  goals  of  the  CSS 
architecture  are  in  accord  with  those  of  the  COPERNICUS 
architecture,  and  aim  to  provide  the  tactical  commander  with 
cost-effective  C*I  capabilities  necessary  for  proficient  C^  in 
the  future: 

•  increased  communications  survivability  via  automated 
access  for  all  users  to  multiple  media,  without 
sacrificing  user  throughput  or  communications  efficiency; 

•  increased  responsiveness  to  rapid  changes  in  war fighting 
information  transfer  requirements  by  permitting  near-real¬ 
time  reconfiguration  of  communication  connectivity  to 
support  changing  priorities  of  information  exchange; 
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•  means  for  Incorporating  new  communications  capabilities 
without  requiring  changes  to  the  user's  baseband  equipment 
or  operating  procedures; 

•  maximized  use  of  existing  communications  equipment; 

•  minimum  impact  upon  funding  profiles  of  existing  and 
planned  programs; 

•  lower  future  communication  system  development  and  life 
cycle  support  costs;  and 

•  simplified  communication  system  operation  and  maintenance. 
[Ref.  5:pp.  2-2  -  2-3] 

These  architectural  goals  will  be  discussed  in  further  detail 
at  the  end  of  this  chapter. 

B.  DESCRIPTION  OF  CSS 
1 .  CSS  Components 

In  order  to  discuss  the  functional  capabilities  of  the 
CSS,  it  is  important  to  have  a  basic  understanding  of  the 
components  which  make  up  the  system.  The  following  defined 
terms  will  enable  the  reader  to  better  visualize  the 
connectivity  CSS  will  provide  among  Copernican  TADIXS  network 
members . 

A  CSS  user  is  a  communications  device.  A  device  may 
be  a  STU  III  for  voice  communications,  a  FASTT  workstation,  or 
a  teletype  (TTY) .  CSS  and  its  users  will  be  located  at  the 
CCC,  the  SEW  Center,  where  the  CSS  GLOBIXS/TADIXS  interface 
will  be  managed,  and  aboard  TCCs. 

A  CSS  subscriber  is  a  device  or  software  within  CSS 
which  interfaces  directly  between  the  user  and  the  CSS 
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standard  Communications  Environment  Communications  Services 
(SCE  CS) ,  providing  one  or  more  users  access  to  the  CSS  [Ref. 
5:p.  2-3].  (The  SCE  CS  is  a  section  of  the  CSS  and  will  be 
described  later  in  this  chapter.)  Using  the  previous  example, 
a  FASTT  subscriber  would  allow  a  particular  FASTT  to  interact 
with  CSS;  a  TTY  subscriber  would  allow  a  particular  TTY  to 
interact  with  CSS. 

A  CSS  service  will  be  able  to  accept/deliver 
incoming/outgoing  information  to  a  common  community  of 
subscribers  [Ref.  8].  A  service  is  similar  to  a  circuit; 
however,  it  is  defined  by  factors  more  in  keeping  with  the 
activation  of  a  TADIXS  virtual  network:  the  time  period  ;:he 
service  will  be  available;  type  of  information,  or  operational 
format  (digitized  data,  voice,  imagery) ,  which  will  be 
transmitted  over  the  service  and  associated  resources  and 
access  to  these  resources;  security  requirements;  delivery 
characteristics  of  the  service  (time,  degree  of  reliability, 
accountability)  ;  and  the  participants  (subscribership)  of  the 
service  [Ref.  7:pp.  5-6]. 

A  CSS  resource  will  consist  of  a  CSS  Subnet  Access 
Control  (SAC)  segment,  a  CSS  Link  Access  Radio  Group  (LARG) , 
and  the  transmission  medium  to  which  the  information  is 
applied  [Ref.  6:p.  33].  (Descriptions  of  the  SAC  and  the  LARG 
are  included  in  the  CSS  Software  Segments  section.) 

Resources  are  initially  planned  to  provide  data  rates 
of  75  bps  to  4.8  kbps.  The  NECC  will  operate  at  up  to  2.4 
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kbps.  Once  additional  SHF  and  commercial  SATCOM  terminals  are 
fielded  for  the  fleet,  resources  may  provide  up  to  256  kbps 
[Ref.  8J;  the  incorporation  of  T1  rates  (1.544  Mbps)  into  CSS 
operations  is  also  planned  for  the  future  [Ref.  10]. 

2.  Multimedia  Aceesa  and  Resource  Sharing 

CSS  will  allow  one  service  to  use  more  than  one 
resource.  This  capability  is  termed  multimedia  access. 
Examples  of  this  are  a  service  that  could  be  transmitted  by 
one  or  more  UHF  SATCOM  radios  over  several  UHF  frequencies,  or 
a  service  that  could  be  transmitted  by  one  or  more  radios  over 
separate  frequency  bands  (e.g.,  EHF  and  UHF  SATCOM).  On  the 
other  hand,  one  resource  may  be  used  to  support  'multiple 
services;  this  CSS  function  will  be  known  as  resource  sharing. 
[Ref.  7:p.  7] 

As  shown  in  Figure  4  [Ref.  5;p.  A-2],  CSS  will 

actually  support  four  cases  of  service-to-resource  matching: 

•  one  resource  supporting  one  service 

•  one  resource  supporting  multiple  services 

•  multiple  resources  supporting  one  service 

•  multiple  resources  supporting  multiple  services  [Ref.  5:p. 

A-2] 

It  is  planned  that  each  service  may  be  assigned  to  as  many  as 
eight  different  resources,  and  that  up  to  16  services  may  be 
allocated  to  a  single  resource  [Ref.  6:p.  23]. 
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Figure  4.  Matching  Services  to  Resources 


The  amount  of  resource  usage  allotted  to  each  service 
will  be  determined  by  the  service  priority  ,  data  precedence 
(COPERNICUS  architecture  documentation  refers  to  data 
precedence  as  "case”),  and  Percent  Allocation  of  Resources 
(PAR)  values  defined  in  a  CSS  connection  plan  (CNCTNPLAN)  or 
entered  by  the  CSS  operator.  The  CNCTNPLAN  will  be  derived 
from  a  matrix  incorporated  into  a  future  version  of  the  NWP 
that  will  define  services  based  upon  Joint  doctrine, 
USCINC/FLTCINC  OPLANs  and  communications  plans  (COMMPLANs) 
[Ref.  l:p.  6-3].  CNCTNPLANs  will  be  discussed  further  in 
Chapter  V. 

Because  of  these  values,  new  users  within  a  TCC  will 
be  accommodated  on  a  priority  basis.  No  new  radios  should  be 
required  to  support  a  new  user  unless  the  total  capacity  for 
a  platform  is  exceeded  [Ref.  7:p.  vi].  However,  if  a 
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platform's  capacity  were  to  be  exceeded,  CSS  would  facilitate 
effective  communications  management  by  using  the  service 
priority,  data  precedence  and  PAR  values.  A  more  detailed 
description  of  how  these  values  are  used  is  included  in  the 
next  section. 

3 .  CSS  Segments 

CSS's  major  functions  are  software,  not  hardware, 
related  [Ref.  9].  Familiarity  with  its  segments  and  their 
functions  will  facilitate  further  understanding  of  CSS  and  how 
it  will  provide  multimedia  access  and  resource  sharing. 
Therefore,  an  overview  providing  brief  descriptions  of  the  CSS 
segments  follows. 

a.  The  Hardware  Segment 

The  Communication  Controller  (CC)  segment  is  the 
physical  multiprocessor  computer  base  in  which  CSS  functions 
will  be  executed.  All  software  segments  will  physically 
operate  in  one  or  more  computers  using  technology  similar  to, 
but  not  limited  to,  the  DTC-2  series  [Ref.  3].  (The  DTC-2  is 
a  workstation  for  the  Naval  Tactical  Command  System  (NTCS) ) . 
The  current  standard  is  the  680X0  series  of  multiple  processor 
computers  [Ref.  8]. 

The  number  of  CCs  on  a  TCC,  or  platform,  will 
depend  on  the  platform's  physical  layout/ avail able  space,  or 
perhaps  its  requirement  to  support  both  Special  Intelligence 
(SI)  and  General  Service  (GENSER)  information  security 
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requirements  [Ref.  7:p.  39].  If  there  is  more  than  one  CC  on 
a  TCC,  there  will  be  communication  between  the  CCs  to  ensure 
that  all  of  the  TCC's  resources  are  shared  among  subscribers 
[Ref.  7;p.  38]. 

Should  CC  failure  occur,  the  TCC  will  have  two 
options:  continue  to  operate  with  the  services  established 
prior  to  CC  failure;  or  revert  to  non-CSS  operations, 
returning  to  nonvirtual  circuitry  through  manual  patching 
[Ref.  7:p.  38].  CSS-capable  platforms  will  be  able  to 
communicate  with  non-CSS  platforms  (either  US  or  allied) .  In 
these  instances,  however,  a  service  will  require  a  single, 
dedicated  resource  without  the  use  of  CSS  protocols  [Ref.  7:p. 
7]. 

The  CC  will  contain  one  or  more  central  processing 
units  (CPUs),  memory,  and  input/output  interfaces  [Ref.  7:p. 
43].  Additionally,  the  CC  will  have  some  hard  disk  storage 
capacity  and  be  modularly  expandable  to  support  system  growth 
[Ref.  7:p.  41]. 

b.  The  Software  Segments 

As  mentioned  earlier,  CSS's  success  and  the  bulk  of 
its  design  deals  with  each  separate  software  function  and  the 
organization  of  those  functions  [Ref.  7;p.  37].  With  the 
exception  of  the  Link  Access  Radio  Group  (LARG) ,  which 
consists  of  both  hardware  and  software,  the  following  segments 
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will  comprise  the  CSS  software.  Figure  5  [Ref.  11]  depicts 
how  the  software  segments  are  linked. 

The  Operating  System/Inter-Process  Communication 
(OS/IPC)  segment  provides  the  operating  system  functions  and  • 

communication  between  segments  [Ref.  7:p.  7]. 

The  Subscriber  Interface  Control  (SIC)  segment  is 
the  interface  between  the  subscriber (s)  and  the  CSS 
resource (s).  Components  of  the  SIC  will  provide  data 
transport  reliability  and  accountability,  and  perform  resource 
selection,  flow  control  and  status  monitoring  procedures  for 
a  specific  subscriber.  A  Subscriber  Data  Unit  (SDU)  is  the 
amount  of  information  that  the  subscriber  treats  as  a  logical 
unit.  The  SIC  will  receive,  buffer,  process  (for  reliability 
and  accountability) ,  and  pass  incoming  SDUs  from  a  resource  to 
the  subscriber;  it  will  receive,  process  and  route  outgoing 
SDUs  from  the  subscriber  to  the  appropriate  resource.  If 
several  resources  have  been  assigned  to  a  service,  the  SIC 
will  continuously  decide  which  resource  to  use  for  outgoing 
SDUs.  Thus,  if  a  resource  were  to  malfunction,  the  SIC  would 
send  its  SDUs  to  the  other  resource  automatically  with  little, 
if  any,  disruption  of  communications.  [Ref.  7:pp.  10-11] 

The  SIC  will  also  perform  internet  routing.  It 
will  receive  SDUs  from  one  resource  and  automatically  reroute  * 

them  to  another  resource  in  order  to  reach  a  destination. 

This  capability  will  provide  connectivity  between  platforms 
that  do  not  share  common  resources.  [Ref.  8] 
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Figur*  5.  CSS  Functional  Partitions 
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The  Resource  Access  Control  (RAC)  segment  is  the 
interface  between  SICs  and  the  resource.  There  will  be  one 
RAC  per  resource.  The  RAC  will  send  incoming  SDUs  received 
from  a  radio  subnetwork  to  the  proper  SIC.  It  will  also 
receive  SDUs  from  the  SICs  and  determine  the  appropriate  order 
of  transmission  over  the  subnet.  The  RAC  will  provide  status 
information  to  the  SIC,  including  expected  waiting  times  (by 
service)  and  the  current  subnet  connectivity,  allowing  the  SIC 
to  choose  the  best  transmission  resource  among  those  resources 
defined  in  the  CNCTNPLAN  for  its  use.  [Ref.  8] 

It  is  here  where  resource  sharing  is  made  possible. 
The  RAC  will  maintain  a  transmit  queue  for  each  service. 
Selection  of  SDUs  for  transmission  will  be  based  on  the 
service  priority,  data  precedence  and  PAR  values  according  to 
the  CNCTNPLAN  in  effect.  (The  PAR  parameter  signifies  the 
default  percentage  of  the  resource's  transmission  capability 
allocated  to  each  service  supported  by  the  resource.)  [Ref. 

6:p.  26] 

Each  queue  will  be  examined  for  service  priority. 
The  SDU  with  the  highest  service  priority  will  always  be 
selected  for  transmission.  If  several  queues  have  equal 
priority,  the  algorithm  for  transmission  selection  in  the  RAC 
will  determine  the  next  SDU  to  be  transmitted.  The 
determination  will  result  in  either  of  two  cases,  depending  on 
whether  data  precedence  processing  is  being  used: 
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•  Data  preoedenca  processing  enabled.  When  several  queues 
have  equal  priority,  the  SDU  with  the  highest  precedence 
will  be  selected  for  transmission.  If  several  queues  have 
the  same  precedence,  the  highest  priority/highest 
precedence  SDU  from  the  service  which  has  not  yet  exceeded 
PAR  will  be  selected.  If  neither  queue  has  exceeded  PAR, 
the  oldest  SOU  with  highest  priority  and  precedence  will 
be  selected. 

•  Data  precedence  processing  not  enabled.  When  several 
queues  have  equal  priority,  the  SOU  from  the  service  which 
has  not  yet  exceeded  PAR  will  be  selected.  If  neither 
queue  has  exceeded  PAR,  the  oldest  SDU  with  highest 
priority  SDU  will  be  selected.  [Ref.  6:pp.  25-27] 


Figure  6  [Ref.  3]  further  illustrates  resource  sharing  and 
multimedia  access. 

The  Subnet  Access  Control  (SAC)  segment  will 
exchange  incoming/outgoing  SDUs  with  the  RAC,  and  will  provide 
the  transmission  access  control  for  a  radio  subnetwork  [Ref. 
9].  It  will  also  provide  other  subnet  management  functions 
such  as  subnet  activation  and  deactivation,  and  member  entry 
and  exit  control  [Ref.  8].  It  will  furnish  to  the  operator 
the  SAC'S  status,  subnetwork's  status,  status  of  each  network 
member,  and  the  estimated  delivery  time  to  each  member  [Ref. 
6:p.  25] . 

The  Link  Access  Radio  Group  (LARG)  is  a  combination 
of  both  hardware  and  software  that  provides  link  level 
encryption;  modulation/demodulation;  encoding/decoding; 
multiplexing;  the  radio;  and  antenna  [Ref.  6:p.  33].  The  SAC 
and  the  LARG,  along  with  the  transmission  medium,  constitute 
a  CSS  resource. 
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The  System/Site  control  (SSC)  segment  will  be 
responsible  for  maintenance  and  dissemination  of  systemwide 
communication  information  and  will  enable  a  communications 
planner  to  match  resources  to  services  [Ref.  7:p.  12].  It 
will  monitor  the  CSS  hardware  and  software  status  and,  with 
operator  assistance,  control  the  CSS  hardware  and  software 
configurations  whereby  a  new  CNCTNPLAN  may  be  designated  [Ref. 

6:p.  11]. 

The 
Operator  Interface 
Control  (OIC) 
segment  will 
provide  a  display 
window  using  a 
standard  X-Windows 
server  and  a 
keyboard/trackball 
operator  input 
device  [Ref.  8].  The  OIC  will  accept  commands  from  the 
operator,  and  will  support  the  operator  functions  described  in 
the  next  section.  [Ref.  7;p.  12] 

Finally,  the  File  Server/Control  (FSC)  segment  will 
provide  storage  and  retrieval  of  information  when  required  by 
other  segments  [Ref.  7:pp.  7-8]. 


Figure  6.  CSS  Resource  Sharing  (top)  and 
Multimedia  Access  (bottom) 
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c.  The  Standard  Communications  Environment 
Communication  Services  (SCB  CS)  and  the  SCB 
Standard  Operating  Environment  (SCB  SOB) 

»  The  SCE  CS  Includes  the  SSC,  subscriber  level 

security,  the  SIC  and  the  RAC.  The  remaining  software 
segments  make  up  the  SCE  Standard  Operating  Environment  (SCE 
SOE)  ;  the  OIC,  the  OS/IPC  and  the  FSC.  Figure  5  [Ref.  11] 
demarcates  the  SCE  and  SOE  areas. 

The  CSS  Standard  Communications  Environment 
Communication  Services  (SCE  CS)  has  standard  external 
interfaces  (to  the  subscriber  and  SAC)  and  standard  internal 
interfaces.  In  order  for  new  radio  subnets  to  function  with 
CSS,  their  design  must  conform  to  SCE  interface 
specifications.  In  this  manner,  new  subnets  may  be  added  to, 
and  be  interoperable  with,  the  SCE  by  connecting  a  new 
subnet's  SAC  and  subscriber  to  a  CSS  RAC  and  SIC 
(respectively)  via  the  standard  SCE  interface.  [Ref.  8] 

4.  CSS  Operator  Functions 

The  OIC  is  designed  as  the  interface  between  the 
operator  and  the  CSS.  On  one  platform,  many  operators  could 
have  access  to  the  CSS ,  depending  on  the  number  of  CSS 
workstations  located  on  it  (e.g.,  radio  room  operator,  battle 
♦  group  communications  planner).  [Ref.  7;p.  28] 

Since  all  operators  will  not  be  required  nor  need  to 
know  how  to  perform  all  CSS  functions,  operators  will  be 
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assigned  different  levels  of  access  to  CSS  based  on  their 
duties  and  responsibilities.  At  each  CSS  site,  the  SOE  will 
contain  an  access  list  with  the  name  of  each  user,  level  of 
access,  and  password  which  will  allow  him/her  access  up  to 
that  level  within  the  system.  A  person  designated  as  the 
site's  CSS  system  administrator  would  manage  and  maintain 
control  over  access  to  CSS.  [Ref.  7:p.  28] 

Automated  network  monitoring  and  management 
capabilities  are  provided  by  the  CSS  to  assist  operators  in 
monitoring  and  controlling  the  real-time  allocation  of 
communications  resources  [Ref.  3].  The  OIC  will  interface 
with  the  operator  via  the  X-Windows  display  in  the  form  of 
user  friendly  menus  on  the  terminal's  color  monitor  screens. 
The  menus  implemented  will  conform  to  the  User  Interface 
Specifications  for  Navy  Systems  [Ref.  12],  which  will 
standardize  menu  presentation  for  Human  Machine  Interface 
(HMI)  users  of  both  afloat  and  ashore  FASTTs.  The  operator 
will  simply  select  the  option (s)  he/ she  desires  from  the 
functions  offered  by  the  menu.  As  mentioned  earlier,  not  all 
operators  will  have  access  to  each  feature.  The  main  menu  of 
the  CSS  console  will  provide  the  operator  having  authorized 
access  and  the  proper  permission  level  with  the  following 
options: 

•  CONNECTION  PLAN.  The  main  features  offered  here  will 
allow  the  operator  to  select  a  CNCTNPLAN  by  file  name  from 
the  platform's  data  base,  view  it,  edit  it,  activate  it  if 
desired,  or,  if  necessary,  delete  it  from  the  data  base. 
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•  MONITOR.  This  feature  will  furnish  the  operator  with  the 
status  of  the  system:  inactive  segment (s)  will  be 
identified;  the  current  ENCON  level  and  conditions  will  be 
indicated;  a  list  of  subscribers  at  the  site  and  their 
locations  may  be  given;  access  will  be  provided  to  SIC 
segments  assigned  to  each  subscriber;  available  and  active 
resources  will  be  identified  and  their  current  status  will 
be  indicated;  test  messages  may  also  be  run  here  in  order 
to  locate  system  errors. 

•  MAIL.  This  function  is  similar  to  electronic  mail  (E- 
mail)  ,  and  will  allow  informal  coordination  among 
terminals  located  on  a  TCC,  or  with  other  CSS  platforms. 
This  feature  will  be  very  helpful  to  platforms  for 
coordinating  the  initial  CNCTNPLAN  configuration  and  when 
subsequent  reconfigurations  are  required. 

•  REPORTS .  This  attribute  will  provide  its  information  to 
the  operator  in  either  graph  or  textual  form.  Information 
will  consist  of  performance  statistics:  the  current 
transmission  status,  the  number  of  SDUs  submitted,  the 
transmission  rate,  and  the  average  queue  time. 
Additionally,  a  day  file,  or  journal,  will  automatically 
log  the  commands  performed  by  an  operator  in  a  24-hour 
period. 

•  SYSTEM  MANAGEMENT .  This  particular  function  will  be 

available  only  to  authorized  personnel  with  the 
appropriate  password.  Capabilities  residing  here  are: 
Configure  Hardware,  to  provide  CSS  the  site's  current 
hardware  configuration;  Configure  Site,  to  provide  CSS 
the  site's  current  software  configuration:  Network 
Management,  to  review  current  workstations,  add/remove 
workstations,  run  LAN  diagnostics,  check  network  status; 
Operator  Access,  to  list  operators,  access  levels, 
passwords;  Backup  System,  to  create  a  backup  for  the  data 
base;  Recover  System  to  restore  a  site's  data  base  from  a 
backup;  Update  Software,  to  load  new  software  when 
upgrading  a  software  segment;  Restart  System,  to  resolve, 
for  instance,  timing  problems  (this  option  will  be 
selected  in  extreme  circumstances  only,  since  this  would 
result  in  halting  all  site  communications) ;  Shutdown 
System,  to  terminate  all^  CSS  operations  on  a  platform 
(usually  during  maintenance/ long  inport  periods) . 

•  UTILITIES.  Capabilities  offered  for  the  operator's 
personal  use  will  be  a  calculator,  scratch  pad,  a  logout 
option,  selection  of  display  attributes,  and  the  ability 
to  change  the  password  of  his/her  own  account. 
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•  APPLICATIONS .  This  section  will  allow  the  operator  to 
enter  a  TADIXS  network  from  the  CSS  operator's  console, 
converting  it  to  a  service  workstation.  [Ref.  7:pp.  28-35] 

Operators  will  be  alerted  to  any  resource  losses  or  equipment 
malfunctions,  and  will  be  advised  when  action  is  required  to 
resolve  the  problem  [Ref.  6:p.  14]. 

C.  CSS  CONTRIBUTIONS  TO  C^ 

Service-to-resource  matching  to  support  the  TADIXS 
networks  will  become  more  enhanced  as  CSS  progresses  toward 
complete  implementation,  incorporating  the  entire  range  of 
TADIXS  bearer  services  (transmission  media)  envisioned:  HF, 
VHF,  UHF  Line-of-Sight  (LOS),  and  all  SATCOM. 

UHF,  SHF  and  HF  are  said  to  be  the  frequency  spectra  that 
have  the  greatest  potential  for  near  term  contribution  to 
Copernican  communications  [Ref.  l:p.  B-3].  EHF  SATCOM, 
however,  is  important  because  of  its  jam  resistance.  EHF 
SATCOM  is  also  the  first  Copernican  TADIXS  bearer  service  that 
will  be  accessible  through  the  CSS.  This  will  be  made 
possible  by  the  NECC. 

Because  of  the  extensive  usage  of  UHF  SATCOM  systems  and 
the  Navy's  investment  of  both  time  and  dollars  in  the 
development  of  current  UHF  SATCOM  systems,  it  is  hoped  that 
these  systems  will  be  made  CSS-compatible  as  soon  as  possible. 
Efficient  UHF  SATCOM  TADIXS  services  are  envisioned  by  the 
author  as  capable  of  both  UHF  Demand  Assigned  Multiple  Access 
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(DAMA)  and  CSS  operations.  The  advent  of  the  Tactical 
Intelligence  Subsystem  (TACINTEL)  II  Plus  (shortly  after  NECC) 
should  be  the  first  step  toward  DAMA/CSS  application, 
providing  increased  throughput  and  a  multimedia  capability  to 
TACINTEL  operations  [Ref.  10]. 

1.  The  COPERNICUS  Architecture 

Multimedia  access  and  resource  sharing  will  permit  the 
evolution  of  TADIXS  and  TCC  operations  within  the  COPERNICUS 
architecture.  They  are  the  CSS  features  that  will  allow  the 
tailored  configuration  of  a  tactical  commander's  C^  system 
discussed  in  Chapter  II. 

Selection  of  communications  services,  TADIXS  mix,  and 
communications  resources  will  be  accomplished  via  activation 
by  designated  TCCs  of  a  CSS  CNCTNPLAN  chosen  by  the  tactical 
commander  or  SEWC  (to  whom  this  duty  may  be  delegated) .  The 
CNCTNPLAN  itself  will  be  based  on  the  yet-to-be  developed  NWP 
matrices.  The  CSS  will  empower  communications  planners  with 
the  ability  to  prescribe  service  priority,  data  precedence 
(case)  and  PAR  to  the  communications  services  which  will 
support  the  mission. 

2.  CSS  Architectural  Goals 

Now  that  the  reader  has  been  provided  with  a  working 
knowledge  of  the  system,  the  CSS  Architectural  goals  will  be 
discussed  in  further  detail. 
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a.  Increased  Commanicatxons  Flexibility  and 
Survivability  via  Multimedia  Access 
Increased  communications  flexibility  and 
survivability  via  multimedia  access  will  be  accomplished 
without  sacrificing  user  throughput  or  communications 
efficiency  by  allowing  a  TADIXS  network  to  be  restored  on 
another  resource  (different  radio) .  Users  will  be  able  to 
maintain  uninterrupted  communications  over  several  resources 
without  operator  intervention  [Ref.  9].  This  means  that  in 
the  event  of  the  loss  of  one  resource,  high  priority  services 
will  automatically  continue  operating  over  their  other 
assigned  resources. 

As  an  example,  a  UHF  SATCOM  network  can  currently 
experience  hours  of  degraded  communications  or  total  loss  of 
communications  because  its  assigned  channel  is  experiencing 
interference  or  jamming,  and  because  there  is  no  other 
available  channel  on  which  to  restore  the  network.  However, 
once  CSS  is  fully  implemented,  if  a  UHF  SATCOM  channel  were  to 
be  jammed,  multimedia  access  would  allow  the  TADIXS  networks 
supported  on  that  channel  to  continue  operating  on  another  UHF 
SATCOM  channel,  or  other  media  automatically.  (Capabilities 
available  at  the  IOC  NECC  will  be  discussed  in  Chapter  IV.) 
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b.  IncreasBd  RBsponsiveness  to  Rapid  Changes  in 
Warfighting  Information  Transfer  Requirements 
Additional  flexibility  through  fleetwide 

reconfiguration  may  be  achieved  by  the  activation  of  a  new 
CNCTNPLAN:  different  subscribers;  a  new  TADIXS  mix; 

reallocation  of  resources — using  different,  additional,  or 
fewer  resources;  and  different  service  priority,  data 

precedence  (case)  and  PAR  values.  If  a  battle  group's  mission 
were  to  change,  the  CWC  or  SEWC  would  coordinate  the 
designation  of  a  new  CNCTNPLAN  and  its  activation  with  the 
FLTCINC  and  CCC/SEW  Center  personnel.  The  contents  of  the  new 
CNCTNPLAN  would  be  readily  available  to  all  concerned,  simply 
requiring  retrieval  from  each  data  base. 

Similarly,  additional  flexibility  through 

reconfiguration  may  be  achieved  when  authorized  personnel  make 
changes  at  a  more  localized  level.  For  instance,  the  units  in 
a  Marine  Amphibious  Readiness  Group  (MARG)  may  collectively 
need  to  change  ship/shore  frequencies  to  enhance  operations. 
In  both  instances,  CSS  will  significantly  decrease  planning, 
configuration,  and  network  activation  time,  thereby  increasing 
communications'  responsiveness  to  a  battle  group's  information 
transfer  requirements. 
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c.  Means  for  Incorporating  New  Communications 
Capabilities 

Incorporating  new  communications  capabilities 
without  requiring  changes  to  the  users 's  baseband  equipment  or 
operating  procedures  will  be  accomplished  by  the  CSS  SCE 
specifications.  As  mentioned  earlier,  new  systems  will 
connect  into  the  CSS  with  their  SACs,  SICs  and  subscribers 
designed  to  SCE  CS  specifications.  This  method  of  adding  new, 
interoperable  systems  to  the  CSS  should  also  result  in  minimum 
impact  upon  funding  profiles  of  existing  and  planned  programs, 
and  lower  future  communications  system  development  and  life 
cycle  support  costs  [Ref.  5:p.  2-2]. 

d.  Maximized  Use  of  Existing  Communication  Equipment 
With  the  full,  or  even  partial,  implementation  of 

CSS,  use  of  existing  shipboard  communication  equipment  and 
assets  should  be  maximized  by  faster,  more  efficient 
throughput  of  digital  data.  Communications  equipment 
(resources/radios)  currently  dedicated  for  one  purpose  (e.g., 
CUDIXS,  OTCIXS)  will  no  longer  sit  idle  during  periods  of 
nontransmission.  Other  CSS  services  could  use  resources 
during  those  periods. 

Assets  such  as  UHF  SATCOM  channels  should 
ultimately  be  capable  of  supporting  various  TADIXS  nets, 
instead  of  one  channel  being  limited  to  supporting  one  network 
(e.g.,  CUDIXS)  as  is  done  today.  Whereas  today's  operational 
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requirements  vie  for  scarce  UHF  SATCOM  channels,  it  is  not 
unreasonable  to  say  that  many  valid  requirements  presently 
unsatisfied  may  be  accommodated  in  the  future  under  their 
respective  TADIXS  categories. 

e.  Simplified  Communication  System  Operation  and 
Maintenance 

As  pointed  out  in  the  Operator  Functions  section  in 
this  chapter,  CSS  will  facilitate  operation  and  management  of 
TCC  communications  assets.  CSS  plans  to  provide  a  useful  flow 
of  information  to  SEWC  staff  personnel  and,  in  turn,  allow 
transmission  of  concise  direction  to  TCC  platforms  from  the 
SEWC  staff  personnel.  It  is  also  the  intention  of  CSS  to 
identify  system  problems  and  advise  operators  of  corrective 
actions  early  so  that  CSS  Mean  Time  to  Repair  (MTTR)  will  be 
considerably  enhanced.  [Ref.  5:pp.  4-2  -  4-3] 

D.  SUMMARY 

CSS  is  not  only  a  system,  but  an  architecture  with  C^ 
enhancement  goals  similar  to  those  of  COPERNICUS;  increased 
communications  flexibility,  survivability,  efficiency, 
reliability,  increased  responsiveness  of  communications 
systems,  and  maximized  use  of  existing  communication 
equipment.  Multimedia  access  and  resource  sharing  are  the 
means  by  which  CSS  can  achieve  these  goals. 

An  open  system  architecture  will  facilitate  addition  of 
new  systems  to  interface  with  CSS.  Systems  designed  to  SCE  CS 
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design  specifications  may  be  added  to  the  CSS,  thereby 
permitting  use  of  CSS  resources. 


IV.  THE  MAVY  EHF  COMMUNICATIONS  CONTROLLER  (NECC) 


A.  EHF  COMMUNICATIONS  TODAY 

EHF  communications  came  to  be  developed  under  the  Military 
Strategic  and  Tactical  Relay  system,  Hilstar,  a  joint  program 
designed  to  provide  survivable,  antijam,  interoperable  EHF 
satellite  communications  among  the  services  [Ref.  13:pp.  49- 
51] .  The  recent  conclusion  of  the  Cold  War  has  led  to  a 
reevaluation  of  Milstar.  Whereas  the  majority  of  Milstar's 
circuits  previously  were  planned  to  support  strategic 
requirements,  a  more  tactical  emphasis  has  now  been  placed  on 
the  system.  Tactical  users  now  stand  a  chance  of  greater 
system  usage. 

In  addition  to  the  Milstar  satellites,  the  Navy  also  has 
Fleet  EHF  Packages  (FEPs)  on  FLTSATCOM  (FSC)  satellites  7  and 
8  and  UHF  Follow  On  (UFO)  satellites  4  through  9  [Ref.  l:p.  4- 
25].  The  Navy  EHF  Satellite  Program  (NESP)  terminals  (AN/USC- 
38) ,  are  planned  to  be  installed  on  designated  ships, 
submarines  and  shore  sites,  with  an  IOC  in  FY93. 

Because  of  its  original  objective,  Milstar  stressed 
survivability  over  capacity:  throughput  was  intentionally 
sacrificed  in  order  to  ensure  protection  from  physical  attack, 
low  probability  of  interception,  secure  encryption,  and  very 
high  resistance  to  jamming  [Ref.  13:pp.  51-53].  Consequently, 
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present  EHF  SATCOM  programs  support  only  low  data  rate  (LDR) 
circuit  operations  (up  to  2.4  kbps)  [Ref.  l:p.  8A-12]. 

The  Space  and  Naval  Warfare  Systems  Command, 
COMSPAWARSYSCOM,  is  currently  designing  a  medixim  data  rate 
(MDR)  capability  (up  to  1.544  Mbps)  which,  once  developed,  may 
support  the  Copernican  GLOBIXS  [Ref.  l:p.  8A-12].  This 
capability,  however,  will  not  be  available  at  IOC;  only  EHF 
LDR  communications  will  be  supported  at  that  time. 

B.  THE  NAVY  EHF  COMMUNICATIONS  CONTROLLER  (NECC) 

Under  CSS,  the  Navy  EHF  Communications  Controller  (NECC) 
will  provide  the  bearer  service,  EHFIXS,  to  NESP  terminal 
platforms.  The  NECC  will  be  installed  with  selected  NESP 
terminals  on  both  afloat  (TCCs)  and  shore  sites  (NCTAMS, 
CCCs) .  Due  to  funding  limitations,  not  all  NESP  terminal 
installations  will  be  accompanied  by  NECC  installations 
initially. 

It  is  anticipated  that  six  LANTFLT  ships  and  one  LANT 
shore  site  will  receive  NESP/NECC  installations  first  [Ref. 
13].  This  number  should  be  sufficient  for  initial  TCC/ shore 
site  communications,  creating  an  interim  operational  period 
during  which  new  uses  can  be  ascertained,  problems  resolved, 
and  procedures  developed.  If  wisely  used,  this  interim  period 
can  facilitate  the  transition  to  fleetwide  NECC  operations. 


48 


1 .  Systea  Dascriptlon 


In  order  to  differentiate  between  the  increments  of 
the  CSS  architecture  (of  which  the  NECC  is  a  project,  or 
increment)  and  the  incremental  capabilities  of  the  projects 
themselves,  the  systems'  designers  refer  to  project  increments 
as  builds  [Ref.  14:p.  1].  For  example,  NECC  Build  One  will  be 
available  for  use  in  FY94  [Ref.  10].  since  the  purpose  of 
this  thesis  is  to  discuss  operations  at  NECC  IOC,  the 
remainder  of  this  chapter  will  address  only  NECC  Build  One. 
The  Appendix  [Ref.  15:pp.  110-112]  provides  a  list  of  all 
capabilities  planned  for  NECC  Builds  One  and  Two. 

The  NECC  Build  One  user  community  will  include 
Tactical  Data  Processors  (TDPs) .  (For  clarification,  TDP  is 
the  Joint  Operational  Tactical  System  (JOTS)  application 
software  used  normally  on  a  DTC-2  terminal.  TDP  also  refers 
to  the  Tomahawk  Weapons  Control  System  (TWCS)  and  Mission 
Display  System  (MDS) .  A  terminal  using  TDP  software  is  often 
referred  to  as  a  TDP.)  The  NECC  will  interface  with  EHF 
SATCOM  equipment  (a  standard  CSS  resource)  and  UHF  SATCOM 
equipment  (a  nonstandard  CSS  resource) ,  providing  these  bearer 
services  to  the  users  [Ref.  15;p.  1]. 

UHF  SATCOM  will  not  be  considered  a  NECC  resource  in 
the  CSS  sense  [Ref.  15;p.  14].  In  order  for  a  TDP  to  maintain 
backward  compatibility  with  current  OTCIXS  and  TADIXS  A 
operations,  an  interface  will  be  installed  to  permit  continued 
communications  over  the  UHF  SATCOM  OTCIXS  and/or  TADIXS  A 
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networks  by  the  NECC-TDP  subscribers  [Ref.  15 :p.  28].  (UHF 
TADIXS  A  is  not  to  be  confused  with  Copernican  TADIXS . ) 

NECC  Build  One  will  be  responsible  for  the  following 
segments,  some  of  which  were  described  in  the  previous 
chapter: 


•  The  Hardware  Segment,  or  Communications  Controller  (CC) ; 

•  The  CSS  Standard  Communication  Environment  (SCE) ,  which 
will  provide  configuration  and  monitoring,  data  transport, 
multimedia  selection  and  access,  and  resource  sharing. 
The  SCE  will  consist  of  the  System  Site  Control  (SSC) , 
subscriber  level  security,  the  Subscriber  Interface 
Control  (SIC) ,  and  the  Resource  Access  Control  (RAC) ; 

•  The  CSS  Standard  Operating  Environment  (SOE) ,  which  will 
provide  the  operator  interface,  real-time  multiprocess  and 
multiuser  operating  system,  and  communications  between 
processes  (software  segments) .  The  SOE  will  be  comprised 
of  the  Operator  Interface  Control  (OIC) ,  the  Operating 
System/ Inter-Process  Control  (OS/IPC) ,  and  the  File 
Server/Control  (FSC) ; 

•  The  Connection  Plan  Generator/Security  Manager  (CPG/SM) ; 

•  The  EHF  Subnet  Access  Controller  (SAC) ; 

•  The  EHF  Manager; 

•  The  TOP  Subscriber;  and 

•  The  Advanced  Narrowband  Digital  Voice  Terminal  (ANDVT) 

SAC.  [Ref.  15:pp.  24-25] 


Discussions  on  each  segment  not  described  earlier  follow. 
Figure  7  [Ref.  14 :p.  3]  is  a  proposed  block  diagram  of  the 
NECC  at  Build  One.  (The  Navigation  Data  Source  in  the  figure 
will  be  located  in  the  NECC  data  base  and  will  provide  a 
site's  position  to  other  sites  in  support  of  EHF  transmissions 
[Ref.  17].) 
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The  Connection  Plan  Generator/Security  Manager 
(CPG/SM)  vrill  provide  operators  the  ability  to  generate  and 
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tailor  a  connection  plan  (CNCTNPLAN) ,  and  to  transfer  the 
connection  plan  to  other  sites  [Ref.  15:p.  36].  Different 
levels  of  these  capedsilities  will  be  made  available  to  CSS 
operators,  depending  on  their  Copernican  function:  the  theater 
planning  site  (such  as  the  CCC) ,  the  CWC's  (or  numbered  fleet 
commander's)  site,  or  simply  an  operational  site  (TCC) .  The 
reader  will  become  familiarized  with  CNCTNPLANs  in  the  next 
chapter . 

At  the  planning  site,  theater  and  site  CNCTNPLANs  will 
be  generated,  received,  stored  and  distributed;  NECC  software 
will  be  received  from  a  software  maintenance  activity,  stored, 
distributed  and  managed;  and  key  requests  may  be  generated. 
At  the  site  of  the  battle  group  commander,  CNCTNPLANs  will  be 
received,  stored,  edited  and  distributed,  and  NECC  software 
may  be  received  and  stored.  Operational  sites  will  receive 
and  store  both  site  CNCTNPLANs  and  NECC  software.  Controlled 
access  to  the  NECC  data  base  for  CNCTNPLAN  generation  and 
software  distribution  management  will  exist  at  all  sites. 
[Ref.  15:p.  36] 

The  EHF  Subnet  Access  Controller  (SAC)  will  perform 
the  SAC  functions  described  in  Chapter  III  by  allowing  an 
operator  to  manage  the  EHFIXS  subnetwork.  The  EHF  SAC  will 
also  interface  with  the  CSS  SCE  so  that  the  SCE  may  access  the 
transmit  and  receive  capabilities  of  the  EHF  SATCOM  circuits. 
[Ref.  15:pp.  24,  32] 
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The  EHF  Manager  will  assist  the  NECC  operator  in  the 
planning  and  management  of  EHF  circuits  [Ref.  15;p.  25].  It 
will  allow  the  operator  to  plan  EHF  circuit  configurations  and 
evaluate  how  those  configurations  fit  within  the  constraint  of 
available  NESP  terminal  resources  and  satellite  assets.  It 
will  keep  track  of  resources  and  assets  used  by  EHF  services 
and  will  attempt  to  fit  additional  reguirements  into  the 
remaining  resources  and  assets.  If  availability  or  coverage 
problems  exist,  alternate  configurations  will  be  presented. 
If  there  are  no  feasible  alternatives,  the  operator  will  be 
notified.  [Ref.  16:pp.  13-14] 

The  EHF  Manager  will  present  information  to  the 
operator  regarding  EHF  subnet  configurations  based  on  EHF 
satellite  coverage,  capacity  requirements,  available  payload, 
and  NESP  terminal  resources.  NESP  terminal  configuration 
information,  based  on  the  EHF  circuit  reguirements  entered  and 
existing  terminal  resource  constraints,  will  also  be 
displayed.  [Ref.  15:p.  38] 

The  Tactical  Data  Processor  (TDP)  Subscriber  will 
provide  an  interface  between  TDP  terminals  and  the  NECC  via 
the  CSS  Communications  Controller  (CC)  without  the  need  for 
any  modification  to  the  TDP  terminal  itself.  It  will  maintain 
backward  compatibility  with  the  UHF  SATCOM  resources  that  the 
TDPs  use,  offering  three  options  for  transmission  of  NECC-TDP 
information:  the  user  will  be  able  to  send  his/her  information 
via  UHF  SATCOM,  EHFIXS,  or  over  both  media.  At  TADIXS  gateway 
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shore  sites,  the  routing  decision  will  be  made  at  the  TADIXS 
Gateway  Processor.  EHF  communications  via  the  NECC-TDP 
Subscriber  will  be  similar  to  those  currently  used  by  TDPs  for 
UHF  OTCIXS/TADIXS  A  network  communications.  [Ref.  15:pp. 
24,28] 

The  Advanced  Narrowband  Digital  Voice  Terminal  (ANDVT) 
SAC  is  intended  to  permit  shared  voice  and  data  usage  of  a 
resource  formed  by  the  ANDVT  and  EHF  service.  The  ANDVT  SAC 
is  not  funded  at  this  time.  NECC  Build  One  will  not  include 
an  EHF  SATCOM  voice  capability.  However,  EHF  ANDVT 
communications  will  be  possible  among  NESP  terminal  users 
without  the  use  of  NECC.  Once  funded  and  installed,  the  ANDVT 
SAC  could  provide  a  secure  voice  capability  among  NECC  users. 
[Ref.  15:pp.  33-34] 

2 .  Other  Capabilities 

As  would  be  expected,  the  NECC  will  provide  EHF 
multimedia  access  and  resource  sharing.  NECC  resource  sharing 
will  include  the  CSS  algorithm  defined  by  the  current  SCE 
specifications.  Thus,  use  of  EHF  resources  will  be  based  on 
the  service  priority,  data  precedence  and  PAR  assignments 
designated  by  the  SEWC  staff  in  the  CNCTNPLAN. 

NECC  Build  One  will  also  provide  many  of  the  CSS 
operator  functions  described  earlier  in  Chapter  III: 
accountable  data  transport  service,  embedded  training;  on-line 
documentation;  alerts;  help;  subscriber  level  security;  day 
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file  journal;  CNCTNPLAN  retrieval  and  conversion  to  a  site 
configuration;  site  configuration  edit  and  activation;  site 
configuration  display;  automatic  software-to-hardware 
assignment;  EHF  SATCOM  subnet  selection;  EHF  SATCOM  subnet 
access  sharing;  operating  system  support  for  the  NECC 
segments;  operator  interface  support;  file  services;  and  data 
base  services  [Ref.  15:pp.  29-31]. 

The  Embedded  COMSEC  Adapter  (ECA) ,  or  External  KG-84 
Adapter,  will  provide  subscriber  level  encryption.  It  will  be 
used  within  the  NECC  to  separate  the  NECC  subscriber  and  the 
SCE,  and  will  provide  a  trusted  bypass  for  control  information 
transfer  between  the  subscriber  and  the  SCE  [Ref.  15:p.  44]. 

Figures  8  and  9  [Ref.  14:pp.  26-27]  illustrate 
proposed  shore  TADIXS  gateway  and  shipboard  site 
configurations.  Both  configurations  show  the  TDP  subscriber 
linking  the  CSS  SCE,  the  TDP  terminals  and  the  UHF  resources 
(the  ON-143,  UHF  SATCOM  interconnecting  group  and  the  TD-1271, 
UHF  DAMA  multiplexer)  .  ANDVT  SACs  are  included  in  both 
figures.  The  shore  gateway  configuration  includes  the  TADIXS 
Gateway  Processor.  In  the  shipboard  configuration,  TWCS  and 
JOTS  TDPs  are  depicted. 

C.  NECC  APPLICATIONS 

Until  a  wider  range  of  services  can  be  fully  integrated 
into  the  CSS  (other  SATCOM,  UHF  LOS)  and  the  NECC  (voice, 
TTY) ,  and  before  an  EHF  MDR  capability  is  developed,  the  CSS 
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Figure  8. 

(NCTAMS) 


Conceptual  Shore  Gateway  Site  Configuration 


will  not  function  as  discussed  in  the  previous  chapter. 
Initial  NECC  operations  will  provide  multimedia  access  and 
resource  sharing  among  EHF  services  and  resources  only,  it  is 
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Figure  9.  Conceptual  Shipboard  Site  Configuration 


imperative  that  both  UHF  and  SHF  SATCOM,  as  well  as  other 
bearer  services,  be  made  standard  CSS  resources  as  quickly  as 
possible  in  order  to  provide  increased  communications 
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survivability  and  flexibility  in  support  of  C^.  The  ANDVT 
SAC,  which  could  provide  NECC  a  voice  capability,  is  not 
funded  at  this  time.  If  it  is  not  feasible  to  incorporate 
ANDVT  voice  communications  into  NECC,  it  must  be  incorporated 
into  CSS  via  some  other  CSS  resource. 

1.  Near  Term  Applications 

In  the  near  term,  however,  NECC  will  provide 
considerable  enhancements  to  operations  and  communications 
management.  NECC  will,  in  effect,  offer  the  prototype  Force 
Operations  TADIXS,  intended  to  support  Strike  Warfare,  ASW, 
AAW  and  ASUW.  TADIXS  A  broadcasts  critical  Over-the-Horizon 
Targeting  (OTH-T)  information  to  tactical  units  in  support  of 
Strike  Warfare,  Anti-Surface  Warfare  (ASUW)  and  Anti-Air 
Warfare  (AAW)  missions.  OTCIXS  supports  acknowledgment  of 
receipt  of  mission-critical  TADIXS  A  information  and  ship-to- 
ship/ship-to-shore  OTH-T  transmissions.  A  separate  OTCIXS 
link  enables  Submarine  Operating  Authorities  (SUBOPAUTHs)  to 
transmit  OTH-T  information  to  submarines,  and  enables  the 
transmi  sion  of  oceanographic  and  meteorological  information 
as  well.  Both  networks  support  NTCS  communications  and  permit 
communications  between  NTCS  users  and  other  TDPs,  such  as 
those  used  by  the  Tomahawk  Weapons  Control  System  (TWCS) . 
[Ref.  15:pp.  85-94] 

The  addition  of  an  EHF  capability  to  the  TADIXS  A  and 
OTCIXS  networks  will  improve  C^.  EHF  will  afford  these 
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networks  a  higher  degree  of  resistance  to  jamming  and  OTH-T 
communications  outages. 

The  additional  EHF  OTCIXS  and  TADIXS  A  will  also 
provide  those  UHF  networks  some  redundancy.  The  resultant 
flexibility  might  relieve  some  of  the  dilemmas  that 
periodically  face  communications  managers  and  users  today. 
There  are  three  areas  where  this  flexibility  might  prove 
useful : 

•  Restoral  of  UHF  networks  using  EHF; 

•  Reduction  of  traffic  loading  on  UHF  networks;  and 

•  Support  of  no-notice  UHF  requirements. 

a.  EHF  Restoral  of  OHF  Networks 

Should  either  the  UHF  OTCIXS  or  TADIXS  A  suffer 
outage  or  degradation  due  to  intentional  jamming  or 
unintentional  interference,  NECC  user  network  operations  could 
continue  on  EHFIXS.  Partial  EHF  restoral  by  only  those 
platforms  with  NECC  would  ensure  that  key  players  continued  to 
transmit  and/or  receive  vital  information.  This  information 
could  then  be  passed  to  non-NECC  platforms  via  other  means 
(e.g.,  voice,  orderwire) .  If  UHF  communications  were  lost 
aboard  a  NECC-equipped  ship,  EHF  OTCIXS  and  TADIXS  A 
communications  would  continue. 

Shore  stations  would  benefit  as  well  during  UHF 
satellite  or  some  UHF  equipment  outages.  A  TADIXS  A  keying 
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station  could  still  transmit  EHF  TADIXS  A  if  it  were  NECC- 
equipped;  a  NECC-capable  TADIXS  gateway  could  continue 
operations  over  EHF  SATCOM. 

b.  Reduction  of  UHF  Network  Traffic  Loading 

EHFIXS  could  be  used  to  reduce  loading  during  heavy 
UHF  OTCIXS  traffic  periods.  NECC  subscribers  could  use  the 
EHF  network  to  receive  and  transmit  their  messages,  thus 
lightening  the  load  on  the  UHF  channel  and  allowing  more  rapid 
delivery  of  message  traffic. 

c.  Support  of  No-notice  OHF  Requirements 

Emergency  activations  of  UHF  circuits  could  be 

supported.  For  instance,  a  UHF  DAMA  slot  could  support  a 
sudden  high  priority  requirement  if  NECC  UHF  TADIXS  A  and/or 
OTCIXS  users  temporarily  shifted  to  EHFIXS  operations.  Such 
operations  would  continue  until  the  UHF  DAMA  slot  were 
released  back  for  its  original  use.  Although  this  procedure 
would  result  in  restoral  for  NECC  users  only,  it  might  save  a 
network  from  total  preemption  by  the  higher  priority 
requirement.  This  capability  could  also  be  used  to  support 
lesser  priority  theater  requirements,  such  as  exercises,  at 
the  discretion  of  the  FLTCINC. 

As  shown  above,  even  partial  execution  of  these 
restoral  methods  by  NECC-equipped  platforms  would  contribute 
a  greater  flexibility  to  fleetwide  communications.  Often,  a 
small  amount  of  flexibility  is  all  that  is  required  to  resolve 
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SATCOM  emergencies  and  short-fused  requirements.  As 
additional  systems  are  incorporated  into  CSS  and  NECC, 
communications  flexibility  can  only  increase. 

2 .  Future  Applications 

Some  possible  applications  for  NECC  in  the  future 
include:  expanded  Strike  Warfare  communications  support,  for 
example,  the  transmission  of  Tomahawk  mission  planning 

material  (MPM)  via  Mission  Data  Updates  (MDUs)  to  Afloat 
Planning  Systems  (APS)  aboard  carriers;  intelligence  and 

imagery  support;  communications  services  between  AAW  and  ASUW 
subscribers;  and  Surveillance  Direction  System  (SDS) 
communications  in  support  of  ASW.  [Ref.  15;pp.  85-93] 

EHF  SATCOM  continues  to  be  the  most  jam-resistant  of 
all  satellite  communications.  In  order  to  maximize  use  of  the 

Navy  EHF  communications  system  and  CSS,  and  to  provide  optimal 

.  .  4  . 

capability  to  Navy  C  I,  MDR  EHF  design  and  development  must 

continue  to  completion  and  be  incorporated  into  the  NESP 

terminal  to  operate  with  NECC  for  future  use  of  satellite  MDR 

capability  once  it  becomes  available  on  Milstar. 

D.  SUMMARY 

Due  to  the  previous  emphasis  on  survivability,  the  NESP 
terminal  (IOC  1993)  will  initially  support  circuits  of  up  to 
2.4  kbps.  A  MDR  capability  is  being  developed  by 
COMSPAWARS YSCOM . 


61 


The  NECC  will  be  the  first  communications  system  to 
operate  under  CSS  and,  in  conjunction  with  the  NESP  terminal, 
will  bring  EHFIXS  to  NECC-capable  Tactical  Data  Processor 
(TOP)  sites.  At  NECC  IOC  (1994),  additional  communications 
flexibility  will  be  provided  in  support  UHF  network  restoral, 
UHF  network  traffic  loading,  no-notice  UHF  requirements.  In 
order  to  enhance  jam-resistant  EHF  SATCOM,  MDR  development 
should  continue  to  completion. 
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V.  C88/MECC  PLAimiMG  AMD  MAMAGEMEMT  AT  IOC 


A.  INTRODUCTION 

The  Naval  Ocean  Systems  Center  (NOSC)  [Ref.  7]  provides  an 
approach  to  CSS  communications  planning.  The  first  planning 
stages  in  the  development  of  an  individual  CSS  site's 
connection  plan  (CNCTNPLAN) ,  based  on  a  FLTCINC  communications 
plan  (COMMPLAN) ,  will  be  discussed  here.  The  discussion  is 
based  on  the  approach,  using  the  services  and  resources 
provided  by  NECC  together  with  the  NESP  terminal  at  IOC. 

Many  possibilities  exist  in  the  development  of  a 
CNCTNPLAN;  parameters  such  as  service  priorities  and  PARS  may 
vary  from  theater  to  theater,  from  operation  to  operation, 
from  one  platform  to  another,  or  even  from  one  time  period  to 
another.  A  simple  case  will  be  discussed  here  in  order  to 
point  out  how  the  parameters  might  be  used  to  define  a 
CNCTNPLAN.  Managerial  issues  will  be  discussed  as  they  arise, 
and  any  difficulties  encountered  in  the  process  will  be 
identifii.J.  Recommendations  are  proposed  throughout  the 
procedure.  It  is  hoped  that  the  reader  will  better  understand 
these  parameters  for  planning  purposes,  and  that  he/ she  will 
gain  an  appreciation  for  the  configuration  possibilities  that 
both  CSS  and  NECC  offer. 
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B.  CSS  COMMUNICATIONS  PLANNING  APPROACH 


As  mentioned  earlier,  CNCTNPLANs  will  be  based  on  matrices 
of  a  future  NWP,  and  those  matrices  will  be  derived  from 
existing  Joint  Doctrine,  theater  OPLANs,  and  COMMPLANs  within 
a  FLTCINC's  Area  of  Responsibility  (AOR) .  It  is  anticipated 
that  the  development  of  a  CNCTNPLAN  for  a  TCC  will  be  a  top- 
down  procedure,  starting  at  the  FLTCINC  level  with  general 
guidance  provided  in  the  form  of  CSS  COMMPLAN  reguirements , 
then  working  down  to  the  numbered  fleet  and  battle  group 
commanders.  Lower  command  levels  will  review  the  COMMPLAN 
information  upon  receipt  for  feasibility  and  add  more  detailed 
information,  such  as  frequencies  and  smaller  networks  or 
network  members.  The  completed  COMMPLAN  will  then  be  sent  to 
individual  ships  for  implementation.  Figure  10  [Ref.  7:p.  20] 
illustrates  proposed  planning  functions  at  the  various  command 
levels.  [Ref.  7;pp.  20-21] 

It  is  intended  that  information  be  entered  into  the  CSS 
COMMPLAN  at  the  highest  level  that  information  is  known  [Ref. 
7:p.  21].  For  example,  the  numbered  fleet  commander  or  battle 
group  commander  might  designate  a  UHF  line-of-sight  (LOS)  or 
HF  service  to  support  carrier  flight  operations  and  assign  to 
it  frequencies  obtained  from  the  NCTAMS. 

It  is  recommended  that  close  coordination  with  the  Naval 
Computer  and  Telecommunications  Area  Master  Station  (NCTAMS, 
formerly  NAVCAMS)  be  conducted  by  all  command  levels  in  order 
to  confirm  CSS  COMMPLAN  feasibility  and  to  determine  if  there 
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are  any  requirements  for 
shore  site  involvement. 
The  participation  of  the 
NCTAMS  in  the  planning 
process  within  its 
COMMAREA  is  highly 
valuable  because  it 
often  provides  much 
insight  and  assistance 
to  commanders  both 
ashore  and  afloat. 

It  is  intended  that 
the  first  planning  step 
in  the  development  of  a 
CSS  COMMPLAN  will 
include  the  following 
procedures : 
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•  set  up  services,  by  matching  specific  operational 
requirements  defined  by  the  FLTCINC  to  appropriate 
services  in  order  that  each  resource  requirement  be 
defined; 

•  set  up  resources,  by  identifying  available  resources  based 
on  the  operational  characteristics  of  each  specific 
service  identified  in  the  previous  step; 

•  match  services  to  resources;  then 

•  promulgate  the  information  to  the  n\nnbered  fleet 
commanders.  [Ref.  7:p.  20] 


Each  of  these  steps  will  now  be  discussed  in  more  detail. 
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1.  setting  Up  Services 


CSS  services  will  be  defined  according  to  the  service 
type.  The  type  for  a  specific  service  will  consist  of  its 
particular  characteristics: 


•  data  type,  the  type  of  information  sent  over  the  service, 
may  be  in  message,  digital  voice,  tactical  data,  imagery, 
or  file  form; 

•  delivery  time,  the  case  of  the  information,  and  how 
quickly  it  must  arrive  at  its  destination (s) :  Case  1 
(three  minutes  or  less.  Case  2  (15  minutes  or  less),  or 
Case  3  (three  hours  or  less)  [Ref.  l:pp.  3-9  -  3-12]; 

•  delivery  features,  the  information  may  be  sent  via  point- 
to-point,  multicast  (to  two  or  more  sites,  either 
addressed  to  them  individually  or  via  a  collective 
address) ,  or  broadcast,  and  may  be  accountable  or 
nonaccountable  [Ref.  17]; 

•  security  requirements,  the  information  may  be  SI  or 
GENSER,  and  will  require  a  specific  type  of  crypto 
equipment  and  keying  material  (keymat) ; 

•  subscriber  type,  the  information  may  be  sent  or  received 
via  TOP,  TTY,  or  FASTT  subscribers  [Ref.  7:p.  5]; 

•  service  membership ,  the  CSS  and  non-CSS  platforms  who  will 
be  communicating  within  a  service;  and 

•  theater  service  priority ,  the  recognized  priority  of  a 
service  within  a  specific  COMMAREA.  [Ref.  17] 


Several  of  these  characteristics  require  further  discussion, 
a.  Accountable  and  Nonaccountable  Delivery 

Accountable  delivery  occurs  when  the  sender  is 
notified  that  the  information  was  received.  In  the  case  of 
nonaccountable  delivery,  no  notification  will  be  received. 
Nonaccountable  delivery  might  be  used  for  reports  that  are 
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updated  frequently,  and  consequently  often  superseded.  [Ref. 
17] 

b.  Service  Membership 

It  is  important  that  any  services  that  consist  of 
both  CSS  and  non-CSS  users  be  identified  at  this  step  in  order 
to  simplify  the  subsequent  steps  where  resources  will  be 
identified  and  assigned  to  support  services.  This  is  because 
CSS  users  will  need  to  dedicate  a  resource  to  establish  and 
maintain  communications  with  non-CSS  users.  It  may  even  be 
desirable  to  have  two  similar  services  designated  in  this 
situation:  one  to  support  CSS  communications  among  CSS  users, 
and  one  for  non-CSS  communications.  This  configuration  would 
be  comparable  to  the  dual  UHF/EHF  OTCIXS/TADIXS  A  operations 
that  will  exist  at  IOC.  [Ref.  7:p.  21] 

Although  not  required  at  this  point,  some  or  all 
desired  network  participants  may  be  specified  [Ref.  7:p.  21]. 
As  previously  discussed,  HF  or  UHF  LOS  services  such  as  those 
which  support  MARG  or  carrier  operations  may  be  added,  along 
with  specified  members,  to  a  COMMPLAN  at  lower  command  levels. 

c.  Theater  Service  Priority 

Note  that  theater  service  priority  is  used  on  an 
areawide  basis.  Because  the  CSS  algorithm  permits  each  site 
to  assign  service  priorities  individually,  a  battle  group's 
service  priorities  may  somewhat  differ  from  theater  service 
priorities,  and  a  platform's  CNCTNPLAN  service  priorities  can 
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differ  from  those  of  both  the  FLTCINC  and  the  battle  group 
commander.  The  absolute  priority  of  a  service  within  a 
specific  site's  CNCTNPLAN  may  be  referred  to  as  the  service 
contingency  value  [Ref.  18 :p.  24].  For  instance,  a  ship 
receiving  special  support  via  point-to-point  communications 
with  a  Naval  Computer  and  Telecommunications  Station  (NCTS) 
would  give  that  service  a  very  high  contingency  value,  where 
it  would  not  even  be  listed  in  another  ship's  CNCTNPLAN. 
Thus,  CSS  and  NECC  will  permit  the  CCC,  CWC  or  SEWC,  and  TCCs 
to  designate  theater,  battle  group  and  ship  service  priorities 
respectively.  In  this  chapter,  the  term  service  priority  will 
be  used  to  mean  service  contingency  value  unless  otherwise 
specified. 

It  is  recommended  that  the  CSS  COMMPLAN  contain  the 
theater  service  priority,  but  that  the  CWC,  SEWC  and  TCCs 
assign  to  CSS  services  priorities  appropriate  for  their 
missions  and  special  requirements.  Service  priorities  within 
a  battle  group  or  for  particular  CSS  platforms  could  be 
assigned  and  controlled  by  the  SEWC  or  the  SEW  Center 
personnel.  For  example,  if  a  TCC  had  to  change  service 
priorities  significantly  due  to  a  change  in  mission  or  in 
order  to  improve  its  flow  of  outgoing  traffic,  it  could  report 
the  change  to  the  SEWC  or  SEW  Center  personnel  (either  via 
voice  or  data)  ,  and  report  once  again  when  the  services 
reverted  to  the  original  assignment. 
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Should  guidance  be  required  to  prioritize  services 
within  theater,  the  latest  UHF  SATCOM  Prioritization  Plan, 
developed  by  the  FLTCINCs  and  promulgated  by  CNO,  might  be  of 
some  assistance.  The  plan  lists  types  of  UHF  SATCOM  networks 
in  order  of  precedence  and  serves  as  guidance  for 
communications  planners  when  emergency  preemption  of  a  network 
is  required.  Its  priorities  range  from  1  (highest)  through  5 
(lowest) .  Increments  within  each  priority  provide  further 
definition  of  precedence.  A  UHF  network  classification 
related  to  the  CSS  service  in  question  could  be  identified  in 
the  plan,  and  its  priority  used  as  a  basis  for  discussion 
among  planners  for  prioritizing  CSS  services. 

2.  Setting  Up  Services  at  IOC 

The  CSS  COMMPLAN  being  generated  here  is  in  support  of 
special  operations  where  an  EHF  HICOM  ANDVT  service  is 
required  in  addition  to  the  exchange  of  EHF  OTH-T  information. 
At  NECC  IOC,  EHF  OTCIXS  and  TADIXS  A  networks  will  be 
available.  In  order  to  differentiate  these  networks  from 
their  UHF  counterparts,  EHF  OTCIXS  will  now  be  referred  to  in 
this  chapter  as  OTH-T  COMMS;  EHF  TADIXS  A  will  now  be  referred 
to  as  OTH-T  BCST.  Non-NECC  EHF  services  supporting  ANDVT 
voice  and  TTY  communications  will  also  be  available  [Ref.  17]. 

At  IOC,  NECC  service  characteristics  may  be  defined  in 
the  following  manner: 
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•  data  types  will  consist  of  operator-to-operator  (OTO) 
messages  and  tactical  data  (in  the  form  of  OTCIXS  message 
format) ; 

•  delivery  times  over  OTH-T  services  may  still  be  designated 
by  the  precedences  Flash  (Z) ,  Immediate  (0) ,  Priority  (P) 
and  Routine  (R) ,  since  message  traffic  may  continue  to  be 
sent  out  over  UHF  SATCOM; 

•  delivery  features  offered  will  be  single-  or  multi¬ 
destination  (including  broadcast),  and  accountable  or 
nonaccountable  [Ref.  17]; 

•  security  requirements  supported  by  NECC  will  be  GENSER, 
encrypted  by  KG-84A  crypto  with  the  appropriate  keymat; 

•  subscriber  type  available  will  be  the  TDP  Subscriber; 

•  service  membership  will  be  include  NECC  and  non-NECC 
platforms  at  IOC;  and 

•  theater  service  priorities  may  range  from  1  through  5  (if 
the  UHF  SATCOM  Prioritization  plan  is  used) ,  or  a  larger 
range  of  priorities  may  be  used. 


These  characteristics  will  become  more  important  as  services 
start  to  shift  toward  Copernican  TADIXS  virtual  networks  and 
as  CSS  and  NECC  expand.  In  this  example,  several  service 
characteristics  will  be  used  in  the  sample  COMMPLAN  and 
CNCTNPLAN  at  the  end  of  the  chapter. 

The  CSS  service  list  might  be  considered  a  worksheet 
that  planners  can  use  to  develop  communications  requirements, 
or  that  an  individual  site  can  use  in  developing  its 
CNCTNPLAN.  TABLE  1  is  an  example  of  how  a  CSS  COMMPLAN 
service  list  might  look  at  IOC.  All  six  units  planned  to  have 
NECC  (ships  A  through  F)  are  designated  as  service 
subscribers.  The  CCC  and  a  NCTS  have  been  added  as  shore 
subscribers.  Note  that  HICOM  ANDVT  consists  of  both  NECC  and 
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non-NECC  users.  Ships  X,  Y  and  Z  have  NESP  terminals,  but  do 
not  have  NECC. 

Service  numbers  have  been  added  so  that  they  may  be 
recognized  by  CSS  and  NECC.  It  is  recommended  that  these 
numbers  be  standardized  to  avoid  any  confusion  among  CSS 
sites.  It  is  also  recommended  that  this  standardization  take 
place  during  the  development  of  the  Copernican  NWP. 

Upon  fuller  implementation  of  CSS,  the  service  list 
and  COMMPLANs  could  become  quite  large.  As  COMMPLANs  are 
developed,  the  corresponding  CNCTNPLANs  will  be  entered  into 
each  site's  data  base  and  updated  regularly,  perhaps  via 
Communications  Information  Bulletins  (CIBs)  issued  by  the 
NCTAMS.  Regular  updating  should  facilitate  working  with  both 
COMMPLANs  and  CNCTNPLANs  as  they  expand. 


TABLE  1.  SERVICE  LIST 


SERVICE 

SERVICE  MR 

SUBSCRIBERS 

OTH-T  COMMS 

OCIOOO 

A,  B,  C,  D,  E,  F,  NCTS,  CCC 

OTH-T  BCST 

OBIOOO 

A,  B,  C,  D,  E,  F,  NCTS,  CCC 

HI COM  ANDVT 

HIIOOO 

A,  B,  C,  D,  E,  F,  X,  Y,  Z, 

CCC 

3.  Setting  Up  Resources 

At  this  step,  available  resources  will  be  identified. 
Available  resources  are  resources,  or  percentages  of 
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resources,  not  previously  assigned  to  support  services. 
Actual  definitions  of  the  characteristics  (e.g.,  frequencies) 
of  the  resources  will  be  provided  by  CSS  and  stored  in  its 
data  base,  so  only  identification  of  the  resources  themselves 
will  be  needed.  Resource  frequencies  will  be  expressed  in 
terms  of  frecjuency  band,  not  in  terms  of  any  specific 
frequencies.  For  instance,  the  frequency  band  for  OTH-T  BCST 
will  be  expressed  simply  as  EHF.  [Ref.  7:p.  21] 

It  is  well  noted  that  until  the  SEWC  is  established 
and  SEW  Center  personnel  duties  become  clearly  defined,  the 
FLTCINC  will  continue  to  be  actively  involved  in  all  use  of 
SATCOM  for  accountability  purposes.  Since  this  will  probably 
be  the  case  at  IOC,  an  additional  column  should  be  added  to 
the  resource  list  specifying  which  SATCOM  frequencies  are  to 
be  used.  Once  Copernican  TADIXS  and  doctrine  become  firmly 
established,  however,  this  responsibility  could  be  delegated 
to  SEW  Center  personnel . 

CSS  coordination  and  planning  will  continue  to  be  as 
important  as  they  are  now.  Planning  requirements  that  cannot 
be  met  may  be  identified,  reported  and  corrected  at  lower 
command  levels,  but  it  is  essential  that  the  CSS  shore 
planning  process  be  as  comprehensive  and  accurate  as  possible. 
CSS  planning  tools  should  be  designed  to  include  mechanisms 
that  will  allow  early  identification  of  any  deficiencies.  In 
this  manner,  most  problems  can  be  resolved  at  the  higher 
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conunand  levels  before  promulgation  to  the  fleet,  precluding 
the  need  for  emergency  workarounds. 

4.  Setting  Up  Rasoureas  at  IOC 

NECC  resources  may  be  viewed  at  three  distinct  levels: 
EHF  satellite  capacity  allocation  to  the  FLTCINC  (which  may 
vary  according  to  EHF  satellite  used,  Milstar,  FLTSATCOM,  or 
UFO) ;  the  percentage  of  that  capacity  allotted  to  the  battle 
group  commander  by  the  FLTCINC;  and  an  individual  platform's 
resources,  dependent  on  the  available  satellite  capacity  [Ref. 
10]  .  For  this  reason,  and  because  platforms  will  use  their 
resources  differently,  coordination  with  the  NCTAMS  is  once 
again  stressed. 

Available  NECC  EHF  resources  at  IOC  will  be 
restricted  to  those  platforms  that  have  both  NESP  terminals 
and  NECC  (one  ashore,  approximately  six  afloat) .  NESP 
ship/ shore  terminals  will  contain  twelve  resources,  or  ports: 

•  four  primary  transmit/receive  (75-2400  bps) ; 

•  four  secondary  transmit/ receive  (75-300  bps) ;  and 

•  four  receive  only  (75-300  bps)  [Ref.  10]. 

The  receive-only  LDR  ports  might  be  used  for  receipt  of 
broadcasts.  Four  of  these  ports  will  be  designated  for  NECC 
use  (which  four  ports  is  not  known  at  this  time)  [Ref.  17], 
For  discussion  purposes,  it  will  be  assumed  that  each  NECC 
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platform  will  possess  two  primary  transmit/receive  and  two 
receive-only  NECC  resources. 

A  CSS  resource  list  may  also  be  considered  a  worksheet 
used  by  planners  and  TCCs  in  conjunction  with  the  CSS  service 
list  when  matching  services  to  resources.  TABLE  2  illustrates 
a  sample  COMMPLAN  resource  list  at  IOC.  Identification 
numbers  have  been  assigned  to  each  resource  so  that  CSS  and 
NECC  may  differentiate  among  them.  These  numbers  will  also 
require  standardization  to  avoid  confusion  at  the  next  step 
when  services  are  matched  to  resources.  One  suggestion  would 
be  to  refer  to  a  site's  primary  transmit/receive  EHF  resource 
as  Resource  EHFOOOl;  the  second  primary  transmit/receive  EHF 
resource  as  Resource  EHF0002,  etc.  In  this  manner,  they  can 
be  differentiated  from  other  resources  (VHF,  UHF  SATCOM)  added 
to  CSS. 


TABLE  2.  RESOURCE  LIST 


RESOURCE  NUMBER 

EHF  RESOURCE 

0001 

TRANSMIT/RECEIVE 

0002 

TRANSMIT/RECEIVE 

0003 

RECEIVE 

0004 

RECEIVE 
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5.  Matching  Sexvieaa  to  Rasoureos 

a.  Assigning  Service  Priorities 

CSS  service  contingency  value  will  depend  on  the 
site,  or  platform  (CCC,  TCC) ,  and  its  mission:  networks  which 
directly  support  mission  operations  will  have  a  higher 
priority  [Ref.  7:p.  23].  Since  HICOM  ANDVT  is  a  voice  service 
supporting  the  special  operations,  it  should  be  given  a  high 
priority. 

Recall  that  service  contingency  values  can  vary 
from  one  platform  to  another.  In  this  example,  if  a  ship  were 
not  participating  in  the  special  operations,  it  would  not  be 
required  to  activate  HICOM  ANDVT,  and  HICOM  ANDVT  would  not  be 
in  its  CNCTNPLAN. 

b.  Matching  Services  to  Resources 

As  discussed  in  Chapter  III,  multimedia  access  and 
resource  sharing  will  provide  CSS/NECC  users  four  options: 

•  one  resource  supporting  one  service 

•  one  resource  supporting  multiple  services 

•  multiple  resources  supporting  one  service 

•  multiple  resources  supporting  multiple  services 

CSS  should  be  of  some  assistance  to  both  planners 
and  individual  platforms  by  providing  an  acceptable 
configuration  that  will  satisfy  requirements.  The  QIC  is 
planned  to  provide  tools  and  templates  to  help  determine 
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reasonable  service-to-resource  matching  [Ref.  7:p.  23].  The 
NECC  CPG/SM  will  automatically  track  service  and  resource 
memberships,  providing  the  operator  this  information  in 
display  or  report  form  [Ref.  18;p.  32]. 

Communications  with  non-CSS  ships  will  be 
identified  first  in  order  to  designate  dedicated  resources 
[Ref.  7:p.  22].  After  this  has  been  accomplished,  remaining 
resources  may  be  assigned  to  the  other  services  in  order  of 
descending  priority.  This  will  ensure  that  the  highest 
priority  service  requirements  will  be  satisfied  first. 

c.  Percentage  Allocation  of  Resource  (PAR)  and  Data 

Precedence  Processing 

After  services  have  been  matched  to  resources,  PAR 
will  be  assigned  to  each  service  to  specify  allocation  of 
resources  among  services.  Data  precedence  processing  (where 
delivery  times  are  specified  according  to  case)  may  be  enabled 
at  this  point  to  further  define  resource  sharing. 

6.  Matching  Services  to  Resources  at  IOC 

Matching  services  to  resources  at  IOC  should  be  a 
fairly  straightforward  procedure  since  the  NESP  terminal  will 
provide  all  users  in  the  theater  four  NECC  resources.  EHF 
will  be  the  only  CSS  frequency  band,  and  NECC  EHF  services 
alone  may  be  matched  to  NECC  resources. 

At  IOC,  EHF  communications  will  consist  of  two  types 
of  subscriber  configurations: 
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•  services  among  NECC  users  employing  NESP  terminal  ports 
designated  as  NECC  resources;  or 

•  networks  among  NECC  user(s}  and  non-NECC  NESP  terminal 
user(s)  employing  a  NESP  teirminal  port  [Ref.  17]. 

The  second  configuration  will  be  necessary  because,  as 
mentioned  earlier,  NECC  platforms  will  be  unable  to  use  NECC 
to  communicate  via  EHF  with  non-NECC  platforms.  (NECC  users 
will  still,  however,  maintain  UHF  OTCIXS  and  TADIXS  A 
communications  with  both  non-NESP  and  non-NECC  users.) 
Communications  among  NECC  and  non-NECC  subscribers,  such  as 
HICOM  ANDVT,  will  require  a  dedicated  NESP  terminal  port, 
a.  Assigning  Service  Priorities 

When  assigning  service  contingency  values,  the 
highest  service  priority  should  be  designated  first,  with  the 
lower  priority  services  specified  accordingly.  These  will  be 
based  on  theater  service  priorities,  but  may  not  exactly  match 
them.  For  demonstration  purposes,  both  OTH-T  COMMS  (EHF 
OTCIXS)  and  OTH-T  BCST  (EHF  TADIXS  A)  will  be  assigned  a 
service  priority  of  1,  although  they  could  have  been  given  any 
priority  deemed  appropriate  for  the  operation  being  conducted 
(or  for  a  particular  platform's  needs)  ,  and  do  not  need  to 
have  the  same  priority.  In  case  emergency  restoral  of  CSS 
services  should  be  required,  HICOM  ANDVT  is  also  given  a 
priority.  Since  it  directly  supports  voice  communications 
among  the  FLTCINC,  numbered  fleet  commander  and  BG  commander, 
HICOM  ANDVT  is  also  given  a  priority  of  1. 
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b.  Matching  Services  to  Resources 


Recall  from  Chapter  III  that  for  outgoing 
information,  when  data  precedence  processing  is  enabled  and 
several  queues  have  equal  priority,  the  Subscriber  Data  Unit 
(SDU)  with  the  highest  precedence  will  be  selected  for 
transmission.  If  several  queues  have  the  same  precedence,  the 
highest  priority/highest  precedence  SDU  from  the  service  which 
has  not  yet  exceeded  PAR  will  be  selected.  If  neither  queue 
has  exceeded  PAR,  the  oldest  SDU  with  highest  priority  and 
precedence  will  be  selected. 

Only  Resources  0001  and  0002  have  transmit 
capability,  so  only  the  services  assigned  to  these  resources 
will  require  data  precedence  processing  and  PAR  values. 
Platforms  that  receive  the  OTH-T  BCST  will  not  need  to 
designate  these  parameters.  However,  the  CSS  COMMPLAN  should 
reflect  as  much  information  regarding  receive-only  services  as 
possible  in  case  emergency  preemption  of  services  were 
necessary.  OTH-T  BCST's  service  priority  is  included. 

Looking  at  the  CSS  resource  list,  OTH-T  COMMS  could 
be  assigned  to  Resource  0001,  a  primary  transmit/receive 
resource.  Although  OTH-T  BCST  requires  only  a  receive-only 
resource,  it  must  be  assigned  to  a  primary  transmit/receive 
resource  because  its  data  rate  is  2400  bps.  A  platform 
receiving  OTH-T  BCST  could  assign  it  to  Resource  0002,  using 
only  the  receive  portion  of  that  resource.  (Note,  however, 
that  the  shore  station  that  uplinks  OTH-T  BCST  would  have  to 
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designate  a  transmit/ receive  resource,  using  only  the  transmit 
portion  of  the  resource.) 

The  service-resource  matrix  in  TABLE  3  reflects  a 
configuration  temporarily  dedicating  Resource  0001  to  OTH-T 
COMMS  and  Resource  0002  to  OTH-T  BCST.  (Other  services  could 
be  assigned  to  either  resource  at  a  later  time.)  Resource 
0002  is  assigned  to  OTH-T  BCST,  but  is  not  dedicated  because 
none  of  its  transmission  capability  will  be  used  to  support 
OTH-T  BCST. 

c.  PAR  and  Data  Precedence  Processing 

It  is  important  when  assigning  PAR  to  a  service  to 
remember  that  the  number  of  resources  available  will  depend  on 
how  the  resources  will  be  used.  For  instance,  in  TABLE  3, 
OTH-T  COMMS  is  supported  by  Resource  0001.  This  resource 
supports  no  other  services.  Therefore,  the  PAR  assigned  to 
OTH-T  COMMS  may  be  100,  meaning  that  100  percent  of  Resource 
0001 's  transmission  capability  supports  OTH-T  COMMS.  If, 
however.  Resource  0001  were  already  assigned  to  a  service  or 
several  services,  a  decision  would  have  to  be  made  on  how  that 
resource  would  be  shared  between/ among  the  services.  This 
decision  could  be  made  at  a  platform  level  (if  an  individual 
TCC's  service  were  affected)  or  at  the  SEWC  level  (if  a 
service  with  many  TCC  subscribers  were  affected) ,  and  would 
depend  on  the  service  priorities  involved. 
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TABLE  3.  SERVICE-RESOURCE  KATRIX:  DEDICATED  RESOURCES 


SERVICE 

SVC  MR 

EHF  RESOURCES  | 

NUMBER 

PRIORITY 

PRECEDENCE 

PAR  1 

OTH-T  COMMS 

OCIOOO 

0001 

1 

YES 

100 

OTH-T  BCST 

OBIOOO 

0002 

1 

1 

1 

0 

TABLE  3  also  reflects  that,  since  OTH-T  BCST 
subscribers  only  receive  information,  precedence  and  PAR  do 
not  apply.  The  Precedence  column  is  left  blank.  The  PAR 
column  contains  a  zero  (0) .  Theater  service  priority  is 
retained  for  information  purposes  in  case  an  emergency  such  as 
resource  failure  were  to  occur. 

PAR  assignment  will  also  depend  on  how  much  traffic 
travels  over  each  circuit.  Remember  that  PAR  will  only  be 
used  when  SDUs  awaiting  transmission  by  the  same  resource  have 
the  same  precedence  (if  enabled)  and  the  same  priority:  when 
they  are  in  contention  for  transmission.  In  these  instances, 
the  SDU  from  the  service  which  has  not  yet  exceeded  PAR  will 
be  transmitted  first. 

If  a  service  has  equal  priority  with  another 
sharing  the  same  resource,  but  has  a  higher  volume  of  outgoing 
traffic,  it  should  be  assigned  a  higher  PAR.  In  this  manner, 
its  SDUs  can  experience  a  higher  percentage  of  resource  usage 
before  PAR  is  exceeded  and  they  come  into  contention  with 
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those  of  the  other  service.  If  the  high  volume  service 
exceeds  PAR,  and  the  low  volume  service  has  not,  its  SDUs  will 
start  to  get  "bumped"  by  the  other  service's.  Only  until  the 
low  volume  service  exceeds  PAR  will  the  oldest  SDU  (presumably 
from  the  high  volume  service)  be  selected  for  transmission. 

Keeping  this  in  mind,  two  transmitting  services  of 
equal  priority  sharing  a  resource  may  be  assigned  PAR 
combinations  such  as  45/55,  10/90,  or  70/30  percent, 
indicating  that  they  share  100  percent  of  that  resource's 
transmission  capability.  They  may  also  be  assigned 
combinations  such  as  25/25,  60/20,  or  40/10,  indicating  that 
50,  20,  or  50  percent  (respectively)  of  that  resource's 
transmission  capability  is  still  available  to  support  another 
service,  or  other  services) .  They  will  even  be  able  to  use 
that  resource's  available  capacity  when  no  other  service  is 
using  it  [Ref.  17]. 

In  TABLE  4,  OTH-T  BCST  and  OTH-T  COMMS  share 
Resource  0001.  Resource  0001  supports  no  other  services. 
Since  PAR  applies  to  outgoing  traffic  only,  OTH-T  COMMS  can 
still  be  assigned  all  (100  percent)  of  Resource  0001 's 
transmission  capability.  If  required,  additional  services 
could  share  Resource  0001.  Once  again,  OTH-T  BCST's 
precedence  column  is  left  blank,  and  its  PAR  remains  at  zero 
(0)  . 

In  TABLE  5,  multimedia  access  is  indicated:  two 
resources  have  been  assigned  to  OTH-T  COMMS.  In  this  case. 
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Resource  0001  does  not  support  any  other  services  and  Resource 
0002  supports  OTH-T  BCST,  SO  each  resource's  PAR  of  100 
percent  may  be  assigned  to  OTH-T  COMMS.  This  method  of 
resource  allocation  should  ensure  faster  transmission  of  OTH-T 
COMMS  information  because  its  high  precedence  SDUs  will  have 
two  resources  over  which  they  can  be  transmitted.  Once  again, 
OTH-T  HOST'S  precedence  column  is  left  blank,  and  its  PAR 
remains  at  zero  (0) . 


TABLE  4.  SERVICE-RESOURCE  MATRIX:  RESOURCE  SHARING 


SERVICE 

SVC  MR 

EHF  RESOURCES 

NUMBER 

PRIORITY 

PRECEDENCE 

PAR 

OTH-T  COMMS 

OCIOOO 

0001 

1 

YES 

100 

OTH-T  BCST 

OBIOOO 

0001 

1 

1 

1 

1 

0 

Data  precedence  processing  has  been  enabled  in  all 
cases.  It  is  assumed  that  this  practice  will  be  preferred  in 
most  instances.  Recall  that  in  cases  where  data  precedence  is 
not  enabled  and  SDUs  of  equal  priority  are  in  contention,  PAR 
will  be  used  to  determine  which  SDU  will  be  transmitted  first. 

7.  Promulgating  the  Information 

TABLE  6  is  an  example  of  how  a  COMMPLAN  might  look 
after  the  initial  planning  stage.  The  actual  plan  will  be 
classified  so  that  keying  material  (keymat)  and  any  other 
classified  information  can  be  specified  in  the  plan. 
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(Planners  may  find  it  valuable  to  include  other  information, 
such  as  frequencies,  at  the  initial  planning  step.)  The 
priority  used  here  is  the  theater  service  priority,  or  simply 
the  COMMPLAN  priority.  Resource  0002  indicates  usage  by  the 
NCTS  for  uplinking  OTH-T  BCST  (OB2000) ,  and  by  the  other  NECC 
platforms  for  receiving  OTH-T  BCST  (OBIOOO) .  Note  that  the 
CSS  values  (1,  ¥,  100)  for  NCTS's  use  of  Resource  0002  are 
included.  The  NCTS  might  use  an  available  resource  for  off- 
the-air  monitoring  of  OTH-T  BCST  (OBIOOO) ,  as  Resource  0001 
illustrates. 


TABLE  5.  SERVICE -RESOURCE  MATRIX:  MULTIMEDIA  ACCESS 


SERVICE 

SVC  MR 

EHF  RESOURCES 

NUMBER 

PRIORITY 

PRECEDENCE 

PAR 

OTH-T  COMMS 

OCIOOO 

0001 

1 

YES 

100 

OCIOOO 

0002 

1 

YES 

100 

OTH-T  BCST 

OBIOOO 

0002 

1 

1 

1 

1 

0 

In  order  to  be  complete,  the  COMMPLAN  promulgated  by 
the  CCC  should  contain  all  networks.  Here,  HICOM  ANDVT  is 
included.  Its  entry  denotes  that  it  will  use  EHF  SATCOM  and 
requires  a  non-NECC  NESP  terminal  port.  HICOM  ANDVT  also 
specifies  such  important  information  as  theater  service 
priority,  network  members  and  required  keymat. 
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As  discussed  previously,  CSS  COHMPLANs  will  be 
promulgated  down  to  lower  command  levels  for  review  and 
further  development.  Modifications  to  theater  service 
priority,  precedence  and  PAR  values  may  be  made  at  all  levels, 
depending  on  the  platform's  outgoing  traffic  requirements. 
Numbered  fleet  commanders  may  add  other  networks,  parameters, 
and  frequencies  where  required,  including  alternate 
frequencies  and  the  times  they  are  to  be  used.  Battle  group 
commanders  may  add  other  networks  required  and  match  platforms 
to  services,  assigning  additional  subscribers  to  services  as 
appropriate.  [Ref.  7;p.  23] 


TABLE  6.  A  SAMPLE  CSS  COMMPLAN 


SVC  MR 

SUBSCRIBERS 

KEYMAT 

EHF  RESOURCES 

NR 

PRI 

PREC 

PAR 

OCIOOO 

A,B,C,D,E,F,NCTS, 

CCC 

XXXXXX 

0001 

1 

Y 

100 

OBIOOO 

A,B,C,D,E,F,CCC, 

(NCTS) 

XXXXXX 

0002 

1 

0 

OB2000 

NCTS 

XXXXXX 

0002 

1 

Y 

100 

HIIOOO 

A,B,C,D,E,F,X,y,Z 

CCC 

XXXXXX 

1 

■■ 

84 


Once  he  has  received  the  COMMPLAN,  the  numbered  fleet 
commander  will  review  it  and  make  any  additions  (smaller 
services) ,  specifying  frequencies  and  times  they  will  be  used. 
If  there  are  any  problems,  he  will  advise  the  FLTCINC.  The 
numbered  fleet  commander  will  also  activate  an  individual 
CNCTNPLAN  at  his  TCC. 

Upon  receipt  of  the  COMMPLAN,  the  battle  group 
commander  will  review  it,  delete  the  use  of  Resource  0002  by 
NCTS,  and  promulgate  the  information  regarding  OTH-T  COMMS, 
OTH-T  BCST  and  HICOM  ANDVT  to  the  TCCs  participating  in  those 
networks.  If  the  battle  group  commander  identifies  any 
problems,  he  will  notify  the  numbered  fleet  commander.  The  BG 
commander  will  also  activate  an  individual  CNCTNPLAN  at  his 
TCC. 

As  discussed  previously,  resources  used  from  ship  to 
ship  may  differ,  and  service  priority,  precedence,  and  PAR 
values  may  vary  as  well.  In  order  to  arrive  at  the  ideal 
configuration  at  his/her  own  site,  each  command  will  follow 
the  first  three  steps  of  the  planning  approach:  setting  up 
services,  setting  up  resources,  and  matching  services  to 
resources. 

Upon  receiving  the  COMMPLAN,  operators  will  enter  into 
the  NECC  all  pertinent  information,  based  on  further 
parameters  offered  by  the  EHF  Manager  within  the  NECC.  (These 
parameters  will  be  based  on  NESP  terminal  operations  and 
EHF/Milstar  satellite  and  circuit  operations  [Ref.  16:p.  38].) 
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Once  all  information  is  entered,  the  operator  will  check  the 
site  configuration  to  ensure  it  complies  with  the  CNCTNPLAN. 
If  there  are  no  problems,  the  CNCTNPLAN  will  be  entered  into 
the  site's  CSS  data  base,  where  it  will  be  available  for  call¬ 
up,  modification  if  required,  and  activation  at  a  later  time. 
If  any  problems  exist  with  the  site  configuration,  the 
operator  will  notify  his/her  superior  for  resolution. 

TABLE  7  denotes  the  CNCTNPLAN  of  TCC  A  that  has  been 
entered  into  the  CSS  data  base  and  is  ready  for  activation. 
In  this  instance,  TCC  A  has  assigned  service  priorities  in 
accordance  with  the  CSS  COMMPLAN.  Should  TCC  A  wish  to 
transmit  a  message  to  another  service  member,  the  CSS  would 
provide  the  status  of  that  member  (reachable,  unreachable) . 
Note  that  EHF  resources  used  may  differ  from  site  to  site. 

TABLE  7.  A  SAMPLE  CNCTNPLAN:  TCC  A 


SVC  NR 

SERVICE 

KEYMAT 

EHF  RESOURCES 

NR 

PRI 

PREC 

PAR 

OCIOOO 

OTH-T  COMMS 

XXXXXX 

0002 

1 

Y 

100 

OBIOOO 

OTH-T  BCST 

XXXXXX 

0002 

1 

— 

0 

HIIOOO 

HICOM  ANDVT 

XXXXXX 

• 

1 

1 

1 

— 

— 

SEW  Center  personnel  should  have  available  the 
CNCTNPLANs  of  the  TCCs  within  a  FLTCINC's  AOR  in  order  to 
effectively  manage  fleet  communications.  Until  the  SEW  Center 


86 


comes  into  being,  however,  the  FLTCINC  will  remain  in  control 
of  the  CNCTNPLANs.  He  may  wish  to  delegate  their  management 
to  the  numbered  fleet  commander  who  will,  in  turn,  be 
supported  and  assisted  by  the  NCTAMS. 

C.  CONCLUSION 

Having  just  taken  a  closer  look  at  the  development  of  a 
CSS  COMMPLAN  and  CNCTNPLAN,  it  is  now  easier  to  see  how  a 
CNCTNPLiAN  could  become  tailored  to  the  desires  and 
requirements  of  the  CWC.  Communications  will  be  enhanced  by 
CSS  multimedia  access  and  resource  sharing,  making  better  use 
of  resources.  The  use  of  service  priority,  precedence  and  PAR 
values  will  further  refine  use  of  the  resources,  allowing  the 
CWC,  SEWC  or  shipboard  communications  officer  (COMMO)  to 
control  the  outgoing  traffic  of  a  group  of  TCCs  or  a  single 
TCC. 

TCCs  that  have  a  specific  mission  and  transmit  large 
volumes  of  information  to  support  that  mission  can  adjust 
their  CSS  values  accordingly.  Services  supporting  force 
operations  or  targeting  may  be  assigned  higher  precedence, 
service  priority  and  PAR  values  than  other  services  with  which 
they  share  resources.  If  a  platform  sends  out  equal  amounts 
of  high  priority  operational  and  administrative  traffic,  it 
can  modify  values  to  arrive  at  an  optimum  mix.  These 
practices  will  ensure  that  other  platforms  will  receive  those 
high  precedence,  high  service  priority  messages  first. 
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Because  there  are  many  ways  in  which  to  formulate  a  CSS 
CNCTNPLAN,  it  is  strongly  recommended  that  soon  after  the 
installation  of  NECC,  ample  time  be  provided  for  individual 
platforms  and  groups  of  platforms  to  sample  and  test  various 
CNCTNPLAN  configurations  in  order  to  determine  the  advantages 
and  disadvantages  of  each  one.  Testing  will  enable  service 
members  to  ascertain  which  configuration (s)  provide  them  the 
most  effective  and  efficient  performance  to  meet  their  needs. 

As  CSS  and  NECC  grow,  early  development  and  updating  of 
both  CSS  COMMPLANs  and  CNCTNPLANs  will  become  necessary. 
Planning  and  coordination  among  staffs  at  different  command 
levels  are  once  again  stressed.  These  procedures  should 
expedite  formulation  of  the  plans.  The  more  CNCTNPLANs  that 
exist  in  a  CSS  data  base,  the  easier  it  will  be  for  operators 
to  call  them  up  for  review,  modification  (if  required)  and 
activation.  This  approach  should  prevent  the  need  to  develop 
any  plans  from  scratch  on  short  notice. 

D.  SUMMARY 

A  CSS  connection  plan  (CNCTNPLAN)  may  be  considered  a  set 
of  particular  services,  resources,  and  values  of  service 
priority,  data  precedence  and  PAR  entered  into  an  individual 
CSS  site's  data  base  to  support  an  operation.  Many  types  of 
a  CNCTNPLAN  may  exist  to  support  various  operations: 
parameters  such  as  service  priorities  and  PARs  may  vary  from 
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theater  to  theater,  from  operation  to  operation,  from  one 
platform  to  another,  or  even  from  one  time  period  to  another. 

CNCTNPLANs  will  be  based  on  matrices  of  a  future  NWP,  and 
those  matrices  will  be  derived  from  existing  Joint  Doctrine, 
theater  OPLANs,  and  COMMPLANs  within  a  FLTCINC's  Area  of 
Responsibility  (AOR) .  A  CSS  COMMPLAN  was  developed  based  on 
a  proposed  planning  approach  consisting  of  four  steps: 
setting  up  services,  setting  up  resources,  matching  services 
to  resources,  and  promulgating  the  information. 

The  first  three  steps  will  also  be  used  by  each  CSS  site 
when  entering  its  own  CNCTNPLAN  into  CSS.  An  example  of  a 
TCC's  CNCTNPLAN  was  shown  based  on  the  COMMPLAN  developed  and 
promulgated. 
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VI.  REC0MMEMDATI0M8  AMD  C0HCLU8I0H 


A.  REC0MMEMDATI0M8 

1.  Planning  and  Management  at  C88/MBCC  IOC 

Because  there  are  many  ways  in  which  to  formulate  a 
CSS  CNCTNPLAN,  it  is  strongly  recommended  that  soon  after  the 
installation  of  NECC,  ample  time  be  provided  for  individual 
platforms  and  groups  of  platforms  to  sample  and  test  various 
CNCTNPLAN  configurations  in  order  to  determine  the  advantages 
and  disadvantages  of  each  one.  Testing  will  enable  service 
members  to  ascertain  which  configuration (s)  provide  them  the 
most  effective  and  efficient  performance  to  meet  their  needs. 

As  CSS  and  NECC  grow  through  the  incorporation  of 
additional  communications  systems,  contributing  to  C*I  more 
proficiently,  their  planning  process  will  become  more  complex. 
Although  CSS  is  planned  to  provide  assistance  in  matching 
services  to  resources,  it  is  imperative  that  theater  planners 
at  all  levels  become  well  acquainted  with  these  systems  and 
their  capabilities.  Both  operations  and  communications 
personnel  must  understand  the  alternatives  that  CSS  and  NECC 
can  provide  in  order  to  derive  the  most  beneficial  use  from 
them.  It  is  also  necessary  that  CSS  sytem  designers  must 
provide  adequate  planning  tools  to  CSS  managers  in  order  to 
facilitate  their  jobs  at  IOC. 
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This  knowledge  will  also  facilitate  the  development  of 
the  communications  matrices  that  are  to  be  included  in  the 
Copernican  Naval  Warfare  Publication  (NWP) .  It  is  recommended 
that  standardization  of  CSS  service  numbers  and  resource 
numbers  occurs  during  this  process. 

2.  NECC 

In  Chapter  IV,  it  was  suggested  that  EHF  MDR  design 
and  development  continue  to  completion  and  that  that 
capability  be  incorporated  into  the  NESP  terminal.  A  recent 
document  reflects  that  the  NESP  terminal  will  be  modified  to 
accommodate  EHF  MDR  on  designated  ships  [Ref.  19:p.  8-7]. 

3.  CSS 

In  order  for  the  full  benefits  of  CSS  to  be  realized, 
systems  interfacing  with  CSS  should  include  the  full  range  of 
communications  possible  for  the  transmission  media  being  used; 
data,  voice,  imagery,  and/or  video-teleconferencing.  Only  in 
this  manner  can  CSS  provide  a  truly  survivable  and  flexible 
architecture,  offering  each  type  of  transmission  various 
media,  or  bearer  services,  by  which  it  can  reach  its 
destination. 

4.  COPERNICUS  and  css 

Finally,  the  Navy  must  remain  committed  to  the  CSS 
architecture,  seeing  that  it  continues  to  incorporate  new 
communications  systems  as  they  are  developed,  regardless  of 
any  problems  that  might  occur.  The  worst  thing  that  could 
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happen  would  be  to  suspend  or  cancel  incorporation  of 

additional  coininunications  systems  into  CSS  once  it  has  been 

introduced  into  the  fleet.  Termination  or  delay  in  expanding 

CSS  due  to  lack  of  follow-through  or  lack  of  funds  would 

render  it  a  fragmentary  system,  having  integrated  some,  but 

not  all,  communications  systems  to  interface  with  it.  CSS 

must  be  as  comprehensive  as  possible  in  order  for  Copernican 

TADIXS  and  the  COPERNICUS  architecture  itself  to  be  effective 
2 

C  force  multipliers. 

B.  CONCLUSION 

This  thesis  has  attempted  to  incorporate  all  available 
documentation  on  COPERNICUS,  the  CSS  and  the  NECC  into  a 
single  text  and  common  language  so  that  it  might  be  used  as  a 
quick  reference  by  the  managers  of  these  systems.  By  so 
doing,  it  seeks  to  familiarize  the  reader  with  the  functions 
and  capabilities  of  CSS  and  the  NECC,  and  their  relationship 
to  the  third  pillar  of  the  COPERNICUS  architecture,  TADIXS,  to 
which  they  belong.  This  thesis  has  also  attempted  to  provide 
useful  recommendations  for  planning  and  management  of  the  CSS 
and  NECC  at  IOC. 

It  is  hoped  that  the  reader  has  gained  a  better 

• 

understanding  of  how  CSS  and  NECC  will  interact  within  the 
Copernican  architecture  to  enhance  fleet  communications  and, 
in  turn,  strengthen  and  improve  C^  for  the  CWC,  FLTCINC,  and 
eventually  the  USCINC.  It  is  also  hoped  that  operations 


personnel  and  communications  managers  now  have  a  foundation  on 
which  to  plan  for  CSS  and  NECC  operations  prior  to  IOC. 
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NECC  Capabilities  Sununaiy 


Requirement  Description 


Hardware  Sell  Test 


Auto  Startup 


X'Windows  Interface 


Connection  Plan  Generator 


EHF  Management  Tools 


Trustee  Operator  Access  Control 


Orwine  He^ 


On-Line  Training  And  Documentation 


Off-ine  Diagnostics 


EGA  (Embedded  COMSEC  Adaptor) 


MSD  (Modular  Security  Device) 


Voice  Packet  Service 


Accountable  Data  Transport 


Reliable  Subnet  Transport  Senrioe 


Reliable  End-To-End  Transport  Service 


Packet  Internet 


MuKcast  Transport 


NSNF  Protocol 


KG-d4A  Unk  COMSEC 


TOD  Unk  COMSEC 


Embedded  UHF  SATCOM  Control 


Dual  Redundant  Hardware 


Automatic  Fault  Recovery 


Security  Manager 


Build  1 
(note  2) 


X  (notel) 


NECC  Capabilities  Suminaiy  (cont'd) 


Requirement  Description 

Build  1 
(note  2) 

Build  2 
(note  3) 

Build  2  Option 

TOP  Subscriber 

X 

X 

TTY  User 

X 

Submarine  IXS 

X 

Submarine  Reporiback 

X 

On-Une  Alerts 

X 

X 

Day  File  Journal 

X 

X 

Performance  Monitor 

X 

X 

Configuration  Control 

X 

X 

Multimedia  Selection 

X  (note  3) 

X  (note  4) 

Resource  Sharing 

X 

X 

Single  Beam  EHF  Subnets 

X 

X 

Multi-Beam  EHF  Subnets 

X 

X 

Agile  Beam  Controlled  EHF  Subnets 

X 

Milstar  IBC  Interface  For  Subnet  Control 

X 

NESP  Terminal  Control 

X 

Voice  Internet  Service 

X  (note  5) 

Interoperable  Voice  Service 

X  (note  6) 

UHF  SATCOM  Interface 

X 

X 

ANOVT  Interface 

X  (note  7) 

Voice  Subscriber  Terminal  Interface 

X 

STU-lll  Interface 

X 

TAOIXS  Gatveay  Interface 

X 

X 

SSIXS  Interface 

X 

Note  1:  Build  i  assumes  use  of  SCE  Build  1  product 
Note  2:  Build  1  assumes  use  of  SCE  Build  3  product 
Note  3:  Includes  VME  processor  boards  only 
Note  4:  Includes  dual  redundant  mass  storao* 

Note  5;  Limited  to  mass  storage  and  processor  components 
Note  6:  Requires  use  of  SCE  Build  4  product 
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